I'll just tell why Hibernate did not have them before, and why they do have'em now (just to share experiences)
Why Hibernate did not have them before: Gavin had done some performance analysis (as you had) showing that the claimed performance gain by some users was non-existent. e.g. only a few databases had a 5-10% better performance) Why Hibernate has it now: Reason 1: Users keept begging about the feature :) Reason 2: In some scenarios users was not allowed to update certain fields (a security constraint), but was allowed to read'em. Reason 3: In some scenarios it did had an effect on performance (mainly with large fields not being changed). Hibernate also have the possibility to have N classes mapped to the same "thing" (e.g. a heavyweight one and lightweight one) that could be used in the different scenarios. But by providing support for adjusting the read/write/update/etc. possibilities on the fields you got a more clean mapping model. Just for info, Max ----- Original Message ----- From: "Thomas Mahler" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Sunday, February 23, 2003 8:53 PM Subject: Re: Request for dynamic update-SQL > Hi Kees, > > Kees wrote: > > Hello, > > > > What are the opinions of creating SQL-update statements dynamically ? > > > > It seems that now all fields are written to the database even if they > > have not been changed. So why not create an SQL statement with only > > the changed fields ? Does OJB know which fields have changed ? Would > > this feature make it into OJB ? > > We had this feature in the very early versions of OJB! It's not > difficult to implement and we had ObjectModification objects that told > the broker about the fields to be updated. We called this feature "smart > updates". > But we dropped it at some point. > Here is why: If we always update all fields, we only need one prepared > statement for updating. This can be efficiently cached. > I we want to implement your idea we must cache up to (2^n)-1 prepared > statements if the class has n attributes. > This can not be done efficiently. > > The only alternative would be to use unprepared statements for those > updates. We did some performance tests that showed that the simple > prepared statement (updating all fields) is faster than using > non-prepared "smart-updates" in most cases. > > But as always OJB has a solution! > you can use different class-descriptors for different scenarios. > For reading you can use a class-descriptor with all (say 17) > field-descriptors. > > For high-performance updates you use a class-descriptor that contains > only (say 2) field-descriptors for updated attributes. > > Of course it's also possible to modify class-descriptors at runtime, so > you can even programmatically detect which attributes have changed and > modify the class-descriptor to contain only field-descriptors for those > modified attributes. > > > > > I need this feature because of : > > - background processes which have the exclusive right to write certain > > fields in records (I made sure that foreground processes will not > > write these fiels) can do so without locking mechanisme. (In fact the > > background processes are forbidden to wait for locks. It must have > > kindof realtime responses) > > - Changing one field in a large record has a lot of overhead. > > both requirements are supported with the concept explained above. > > cheers, > Thomas > > > > > I know that hibernate supports this mechanism in 2.0. How about OJB ? > > > > Kees. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
