Hi Joe, Nice to here from the starting developer!
> Anyway, i wanted to ask: i created a local patch which avoids > serializing the whole FileHolder into blob fields. Storing > the FileHolders turned out to be a bad aproach for several reasons: > - change in fileholder class definition etc. leads to awful exceptions > - DbForms is needed to retrieve BLOB data from DB The reason > why i introduced Fileholders in the first place was to store > some file meta data (e.g. filename). My path solves this > problem by adding an interceptor which, on insert/update, > takes the file metadata and stores it into some field specified. > > This way, the file metadata is preserved, but the BLOB is not > polluted by some serialized java wrapper object and can be > accessed by any other app. > > My question is: > - do you want me to add this patch to the CVS +1 > - if so, should i provide a switch between the old and the > new way of handling a Blob? (e.g. i n dbforms-config.xml) Yes, that's good. This should work on a per table base. > - if so, which one should be default (new or old)? The new. Would it be possible to switch to the jakarta httpclient lib instead of the old cos.jar? Regards, Henner ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
