Max Rydahl Andersen wrote:
I'll just tell why Hibernate did not have them before, and why they do have'em now (just to share experiences)
Good idea, thank you!
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)
That matches exactly with my experience.
Why Hibernate has it now: Reason 1: Users keept begging about the feature :)
sounds familiar too...
Reason 2: In some scenarios users was not allowed to update certain fields (a security constraint), but was allowed to read'em.
As in Kees scenario
Reason 3: In some scenarios it did had an effect on performance (mainly with
large fields not being changed).
yes, that's true!
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.
This idea of having policies seems a bit different from the simple "smart update" concept?
thanks, Thomas
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
