From: Chuck H. <ch...@gl...> - 2009-03-30 21:25:53
|
On Mar 30, 2009, at 6:28 AM, Mike Schrag wrote: >> Wouldn't it be better (from a purely DB standpoint) if you didn't >> defer constraints by default? Of course, this would be dragging every >> other DB down to MS SQL Server's level and require use of the Entity >> Ordering code that Chuck wrote. > Personally, I don't think so. The only case I've heard so far for > immediate constraints is triggers and even that is with a particular > subset of triggers that have some constraints on them. I would wager > that most people don't actually have this problem, and if they do, > that's an advanced topic which, to me, would imply that these people > would be more likely to be able to diagnose and work around EOF using > deferred constraints. On the flip side, you would instead break > pretty normal-looking models in ways that don't really make much sense > to people who might not keenly understand the issue. At least one need for the use of deferred constraints as a work around for a defect in EOF: EOF is unable to have the adaptor operations ordered in the same order and the EOControl initiated operations occurred. It does not seem to be undesirable to have EOF generate operations in an order that does not require temporary database inconsistency. > Chuck's code is > very useful, but doesn't actually work in several cases that are much > more common than the cases that fail with deferred constraints. When does it fail? I don't recall any cases other than self- referencing relationships and constraints within a table. Neither IME are more common than cases that fail with deferred constraints. And both can be handled, I am just lazy and did not require them. > Is > there any other common database other than MSSQL that doesn't support > deferred? I haven't heard of any other common ones, which means we > would just be punishing the majority. OpenBase perhaps, there are a couple of others. >> I would just think that having the DB calls done in the sequence >> required by inter-entity dependancies would reduce the complexity of >> debugging dependancy problems. And if there were problems, they'd all >> be in the Java Code and not with potentially different DB >> configurations. > I've never had a dependency problem in my database .... sooooo ... > I've never had to debug one. I feel bad for SQLServer people, but not > bad enough to make my life suck, too :) > >> Also, it better follows WO's concept of DB independence because the >> action of saving to the DB would be the same for every DB, instead of >> now where if you use SQL Server, you must add additional code to your >> project to trigger Entity Ordering. > I consider this a failure of SQLServer, though. There's a limit of > least-common-denominator to me. MySQL w/o InnoDB doesn't have > transactions -- it requires extra config out of the box to turn them > on -- should EOF try to provide some workaround (that would only sort- > of work, anyway) to get around that? Now, I wouldn't be opposed to > the MSSQL plugin maybe automagically turning things on, as long as it > doesn't mess other things up. -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects |