No this is not an announcment. Rather the opposite. I believe I've heard about a version of the Photo product that saves the images on the filesystem. Am I right, is there such a product? Where? My current problem is that my Photos in zope take are so big that I have problems copying folders and can with a little pain back it all up. I bet there are advantages with storing the big binary content on the Linux instead of the ZODB. Hej hej, Peter
From: "Peter Bengtsson" <mail@peterbe.com>
I bet there are advantages with storing the big binary content on the Linux instead of the ZODB.
Only if you need to access the files external of Zope... there's no established performance or space saving (as long as you keep tabs on your undo's)
But it takes longer to restart zope when you have a large ZODB. dj On Thu, 31 May 2001, marc lindahl wrote:
From: "Peter Bengtsson" <mail@peterbe.com>
I bet there are advantages with storing the big binary content on the Linux instead of the ZODB.
Only if you need to access the files external of Zope... there's no established performance or space saving (as long as you keep tabs on your undo's)
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Last time I checked, Zope creates an in-memory index of the entire ZODB on startup, so yes it does take longer to start up with a larger DB. As for the original question, there are two common solutions to your problem: the LocalFS product and the ExtFile/ExtImage product. Search for those on the site, I'm sure one of them will fit your needs. --jfarr ----- Original Message ----- From: "marc lindahl" <marc@bowery.com> To: "Dan Jacobs" <dan@caliginous.com> Cc: "Peter Bengtsson" <mail@peterbe.com>; <zope@zope.org> Sent: Thursday, May 31, 2001 11:46 AM Subject: Re: [Zope] FS Photo product
From: Dan Jacobs <dan@caliginous.com>
But it takes longer to restart zope when you have a large ZODB.
Check back in the list, there was a discussion about that. Somone from DC stated that it's not true if zope is shut down properly.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
On Thursday 31 May 2001 12:48, marc lindahl wrote:
From: "Jonothan Farr" <jfarr@real.com>
Last time I checked, Zope creates an in-memory index of the entire ZODB on startup, so yes it does take longer to start up with a larger DB.
by "larger" meaning, more objects or larger objects?
more objects this is true of fs storage, other storages might not need this... ~kapil
OK, so if it's 'more objects', then it's irrelevant if you're storing the big data inside data.fs, since you're storing an object for each ext file anyway (at least in ExtFile, I'm not sure about LocalFS, since it seems you can use directory views in it?)
From: ender <kthangavelu@earthlink.net> Date: Thu, 31 May 2001 08:27:05 -0700 To: marc lindahl <marc@bowery.com>, <zope@zope.org> Subject: Re: [Zope] FS Photo product
On Thursday 31 May 2001 12:48, marc lindahl wrote:
From: "Jonothan Farr" <jfarr@real.com>
Last time I checked, Zope creates an in-memory index of the entire ZODB on startup, so yes it does take longer to start up with a larger DB.
by "larger" meaning, more objects or larger objects?
more objects
this is true of fs storage, other storages might not need this...
~kapil
It also saves that index as Data.fs.index so in theory its just a matter of opening that file if Zope is shut down correctly. Cheers. -- Andy McKay. ----- Original Message ----- From: "Jonothan Farr" <jfarr@real.com> To: <zope@zope.org> Sent: Thursday, May 31, 2001 12:41 PM Subject: Re: [Zope] FS Photo product
Last time I checked, Zope creates an in-memory index of the entire ZODB on startup, so yes it does take longer to start up with a larger DB.
As for the original question, there are two common solutions to your problem: the LocalFS product and the ExtFile/ExtImage product. Search for those on the site, I'm sure one of them will fit your needs.
--jfarr
----- Original Message ----- From: "marc lindahl" <marc@bowery.com> To: "Dan Jacobs" <dan@caliginous.com> Cc: "Peter Bengtsson" <mail@peterbe.com>; <zope@zope.org> Sent: Thursday, May 31, 2001 11:46 AM Subject: Re: [Zope] FS Photo product
From: Dan Jacobs <dan@caliginous.com>
But it takes longer to restart zope when you have a large ZODB.
Check back in the list, there was a discussion about that. Somone from
DC
stated that it's not true if zope is shut down properly.
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
I started modifying the Photo product to use ExtFile/Image since my memory was getting eaten by it. I ran into a few problems, though I mostly had it working. It turned out, however, that my memory was being eaten because the different photo sizes are stored as *strings*, not as Zope Image objects. Each string was being loaded in full into memory before being served. That eats memory fast. I ended up modifying it to store the different displays as Zope Image objects and my memory problem vanished (since Zope loads Images in pieces). I also managed to fix another bug with regard to the dimensions getting "randomly" messed up. I haven't had time to make any official releases or patches available, but I'll be glad to send them to you if you want to use it even without external file storage. Perhaps I'll continue changing Photo to work with ExtFile/Image someday, but don't hold your breath. _______________________ Ron Bickers Logic Etc, Inc.
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Peter Bengtsson Sent: Thursday, May 31, 2001 11:58 AM To: zope@zope.org Subject: [Zope] FS Photo product
No this is not an announcment. Rather the opposite. I believe I've heard about a version of the Photo product that saves the images on the filesystem. Am I right, is there such a product? Where?
My current problem is that my Photos in zope take are so big that I have problems copying folders and can with a little pain back it all up. I bet there are advantages with storing the big binary content on the Linux instead of the ZODB.
At the moment I have no problem with the Photo metatype except that I can't download my whole site and take it home to improve it because the Photo album section is too big. But if you think that many Image objects is performancly better than one Photo object, maybe it is something I should look into.
I also managed to fix another bug with regard to the dimensions getting "randomly" messed up.
What? What '"randomly" messed up [dimensions]'? Are the dimensions of the different sizes not right? (honestly, a resize in a Photo is worse than when you do it in Photoshop) Peter ----- Original Message ----- From: "Ron Bickers" <rbickers-dated-991773254.7cded5@logicetc.com> To: "Peter Bengtsson" <mail@peterbe.com>; <zope@zope.org> Sent: Thursday, May 31, 2001 10:34 PM Subject: RE: [Zope] FS Photo product
I started modifying the Photo product to use ExtFile/Image since my memory was getting eaten by it. I ran into a few problems, though I mostly had it working. It turned out, however, that my memory was being eaten because the different photo sizes are stored as *strings*, not as Zope Image objects. Each string was being loaded in full into memory before being served. That eats memory fast.
I ended up modifying it to store the different displays as Zope Image objects and my memory problem vanished (since Zope loads Images in pieces). I also managed to fix another bug with regard to the dimensions getting "randomly" messed up.
I haven't had time to make any official releases or patches available, but I'll be glad to send them to you if you want to use it even without external file storage. Perhaps I'll continue changing Photo to work with ExtFile/Image someday, but don't hold your breath.
_______________________
Ron Bickers Logic Etc, Inc.
-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Peter Bengtsson Sent: Thursday, May 31, 2001 11:58 AM To: zope@zope.org Subject: [Zope] FS Photo product
No this is not an announcment. Rather the opposite. I believe I've heard about a version of the Photo product that saves the images on the filesystem. Am I right, is there such a product? Where?
My current problem is that my Photos in zope take are so big that I have problems copying folders and can with a little pain back it all up. I bet there are advantages with storing the big binary content on the Linux instead of the ZODB.
-----Original Message----- From: Peter Bengtsson [mailto:mail@peterbe.com] Sent: Friday, June 01, 2001 3:46 AM To: Ron Bickers; zope@zope.org Subject: Re: [Zope] FS Photo product
At the moment I have no problem with the Photo metatype except that I can't download my whole site and take it home to improve it because the Photo album section is too big.
If this is your only problem, you can always use one of the various utilities to split the Data.fs file into moveable chunks and put it back together when you get it home.
But if you think that many Image objects is performancly better than one Photo object, maybe it is something I should look into.
It's still a Photo object. The Photo object is basically a single Image object (the original image uploaded) and a series of resized objects stored as strings. With my modification, it's a single Image object and a series of resized objects stored as Image objects. I don't know about performance, but memory usage is definitely better with Image objects. My patch will take existing Photo objects and rebuild them when they are first viewed, so there's no need to start over.
What? What '"randomly" messed up [dimensions]'? Are the dimensions of the different sizes not right? (honestly, a resize in a Photo is worse than when you do it in Photoshop)
I don't fully understand what's going on in that part of Photo, but it makes a "copy" of the set of dimensions stored in the Photo product to use with each uploaded Photo. The problem was that when I uploaded a horizontal images (where the x is larger than the y), and then uploaded virtical images (y greater than x) in the same folder, it seemed to randomly swap the dimensions of my horizontal images to be the virtical equivalent, and vice versa. I could reproduce it fairly easily with trial and error, but I couldn't explain a process for someone else to reproduce it. At least one other person reported to me that they had the same problem (and that my fix took care of it), but it's apparently a rare occurrence since I haven't seen any other reports. _______________________ Ron Bickers Logic Etc, Inc.
participants (8)
-
Andy McKay -
Dan Jacobs -
ender -
Jonothan Farr -
marc lindahl -
Peter Bengtsson -
Ron Bickers -
Ron Bickers