Thanks for the clarification Kurt--in my use of Hibernate I just didn't ever even worry about it (which is the beauty of Hibernate!) so I wasn't aware it was an option. You're right on the large fields potentially being an issue. In my previous comments I didn't think about blob or clobs being involved.
On 2/22/06, Kurt Wiersma <[EMAIL PROTECTED]> wrote: > Hibernate does support partial updates on a table where only the changed > fields are updated. I am sure how often it gets used but it is an option. I > suspect one situation might be where you have a table which has several > large blob fields. To save on network traffic and DB processing time it > might be best in case to only update a field if it has changed (which > clearly Hibernate tracks). > > I don't think Reactor needs to implement this, at least not right now but it > is an interesting option. That is just my 2 pesos though. :) > > --Kurt > > On 2/22/06, Matt Woodward <[EMAIL PROTECTED]> wrote: > > On 2/22/06, Porter, Benjamin L. <[EMAIL PROTECTED]> wrote: > > > I agree that the ORM should handle it so the application code can treat > the > > > records as objects, but there is a very valid integrity concern when > > > touching any fields in a database that are not necessary. > > > > I disagree--your database interaction is atomic, or should be at any > > rate. Whether it's one update or 100, the whole thing should either > > succeed or fail so I guess you'll have to expound on what this > > integrity concern is. As long as the object data is valid, and if > > it's not that's on the application's back to handle that, the job of > > the ORM layer is to persist data, not figure out what has and hasn't > > changed. > > > > > Not to mention the > > > additional overhead for the database, and the additional network > traffic. > > > > Both of which would be extremely negligible even in large > > applications. If you find yourself in a situation where you're > > updating so many fields that this matters then it might be time to > > investigate what's going on with the application side of this > > equation. > > > > > There is no reason why an ORM tool can not manage the integrity of a > records > > > state, and only commit changes to the persistence of parts of that > record > > > which have changed. > > > > It's not an issue of whether or not it can, it's an issue of whether > > or not it should. > > > > > I'm not convinced a separate method is necessary for > > > updating by field, but the standard crud methods should consider whether > the > > > record has changed before modifying the persistence. > > > > We'll wind up agreeing to disagree on this point. This isn't the > > ORM's job IMO. In my mind this is a bleed of the concerns of the > > application and/or integrity at the database level into the ORM layer. > > > > > This may not be an issue for medium or small web applications, but for > > > enterprise level applications it is. > > > > I don't really see why; again, the database interaction should be > > atomic and your data integrity should be handled at both the > > application and database levels. The ORM tool's job isn't data > > integrity. And if by "enterprise" you mean "Oh, I'm updating 10,000 > > fields so it matters for network traffic and database overhead," then > > that's likely an object model or other application architecture issue > > you'd want to look into. > > > > Matt > > -- > > Matt Woodward > > [EMAIL PROTECTED] > > http://www.mattwoodward.com > > > > > > > > -- Reactor for ColdFusion Mailing List -- [email protected] > > -- Archives at > http://www.mail-archive.com/reactor%40doughughes.net/ > > > > > > > > -- Reactor for ColdFusion Mailing List -- [email protected] -- > Archives at > http://www.mail-archive.com/reactor%40doughughes.net/ -- Matt Woodward [EMAIL PROTECTED] http://www.mattwoodward.com -- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/
