Ok, this is related to my earlier post. If I have a business object that has an uploaded image associated with it (as a field in the object) then there are two approaches i'm looking at and i could use some insight into which one is better in this situation: 1. The uploaded image gets serialized as some sort of object and stored in a blob (i'm using hibernate). 2. The object only holds the filename of the object, not the object itself and is stored on the server somewhere. In case 1 it is much easier to ensure that the image gets deleted when the object does since hibernate would do that automatically. However, this means I will probably have to write an engine service to handle accessing these images and I'm not sure if web browsers will cache them or not. Also, I would then have to worry about size issues if the object ever gets put into the user's session (which it does). Case 2 is easier to deal with how to get the image off the server (I could just use it as an asset) except that I'm not sure where I would store it. But I'm not sure how I would make sure that the image is deleted from the server when the entity is deleted from the db. Updates pose a similar problem. Any thoughts on how to approach this would be appreciated.
To make things utterly confusing, we do both.
I have all images and binary resources in a blob column. Since we use Hibernate I have made a Hibernate User Type that upon requesting the java.io.File it represents, first check if the file exists in the temporary store, and if not, it streams it out, using the primary key as filename, in a known folder.
This way I can keep the files consistent in database over the cluster of tomcats, in addition to leveraging the staticness of files on disk. This works pretty well, although my Hibernate type needs some harnessing to be completely usable - e.checking for new versions of the binary data in db is not bulletproof yet.
This of course depends on your persistence framework... But I am sure the principle could be used in all settings.
I would be happy to give away details... Just ask.
Hope this helped...
Olve
signature.asc
Description: Dette er en digitalt signert meldingsdel
