Hi,
A nice trick that I got from one of the WO books is to put the blob
attribute in a separate table with the same PK as the primary table.
For example:
Entity: Attachment
PK: attachmentID integer
A: filename varchar(255)
... etc ...
Entity: AttachmentBLOB
PK: attachmentID integer
A: blob binary - NOTE: TURN OFF LOCKING
Relate the two tables to each other (1 to 1) and make sure that
Attachment's attachmentBLOB relationship propagates its primary key.
With a simple blob() getter and setBlob() settter in attachment you
can make this arrangement basically transparent. The getter basically
then just does return attachmentBLOB().blob(); attachmentBLOB cannot
be null as it's a to-one with propagate PK so EO will always create
it. EO will not however always fetch it when fetching from the
database which is the cool thing that makes this trick work. The
setter of course need only do attachmentBLOB().setBlob();
Doing it this way you don't have to give up the greatness of EOF and
you don't have to waste memory storing the blob every time you fetch
an Attachment object. You do of course waste memory if you update the
contents of the blob because EOF will keep the old blob around to
support not only undo but also changesFromSnapshot. IMO it's probably
acceptable but YMMV.
Obviously if the blobs are exceedingly large then you probably don't
want to manage them with EOF at all but whether or not you store them
in the database is really your own business. Most DB are somewhat
optimized for the BLOB case so it's not much less efficient than
storing a path to a file on some (probably networked) filesystem. It
can certainly be said that being able to store all data, even blobs,
in the database makes deployment much easier.
-Dave
On Feb 8, 2008, at 7:44 PM, Lachlan Deck wrote:
On 08/02/2008, at 8:58 PM, Susanne Schneider wrote:
These were my considerations:
- memory consumption while using eos (as I understood the image-
property
would at least be hold twice: once in the eo in every editing context
and once in the snapshot)
If you do store them in the database, consider using raw-row fetches.
The other thing to consider, if serving from WO, for such large
objects is that you'll want to turn
WOAllowsConcurrentRequestHandling on (with all that entails).
with regards,
--
Lachlan Deck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/dfe%40tgwbd.org
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
