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/
