So let me get this straight.... You want a feature request to allow the user/developer to turn off constraint checking on demand?
The example you give is for unit testing.... This really isn't a good feature, or one that should ever be used. Using your example, you want to turn off the constraints that will exist in production for a "unit test". This leads to the scenario that you could perform unit tests without checking/testing with the constraints in place. You really should perform unit tests with the constraints in place. The other issue is that the database is more than the sum of its parts. You have to think of the database as more than just object persistence, and while I'm not suggesting this is the case for Robert, I do believe that even on this list which is a subsection of Derby users/developers, that the "persistence vision" exists. The other issue, when looking at a feature, you still have to consider the TCO of the feature. Not just in maintenance, but also in the increase in footprint size and weigh it against the value that it brings. You're adding excess baggage. I wonder what ever happened to the idea of making Derby more modular where you can set/unset features that you don't want in your production copy. This level of functionality doesn't come cheap, but it will definitely make things "interesting". But hey! What do I know? I'm using POJO for a BPR POC project. Or maybe I'm just old fashioned when it comes to design ... ;-) (BPR = Business Process Re-engineering, POC = Proof of Concept) -G P.S. MySQL is a db that "we" should not emulate when looking at features. (Yes I *am* an Informix bigot, but I also tolerate some others. ;-) > -----Original Message----- > From: Robert Enyedi [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 16, 2006 7:14 AM > To: Derby Discussion > Subject: Disabling foreign key constraints > > Is there a way in Derby to disable foreign key constraints? > > This should be something similar to the SET FOREIGN_KEY_CHECKS = 0 > statement in MySQL which, when set, makes the engine to ignore any > foreign key constraints. > > I know that having the database constraints is the way to go, but for > some scenarios (e.g. unit tests) having partially valid data is just fine. > > Regards, > Robert
