Thanks! I've just checked that up. Actually, db-constraints lib doesn't play well in distributed environment, where tables are located anywhere on the LAN in the separate repositories. As far as I know, Oracle supports foreign key constraints across distributed tables, but MySQL and PostgreSQL do not. Also, I run tests using in-memory SQLite, which doesn't seem to support foreign key constraints.
Anyway, it seems to be a right thing to keep that code in dm- constraints library and also be able to switch off DB-level constraints. Wdyt? On 09.11.2008, at 5:31, Dan Kubb (dkubb) wrote: > Oleg, we actually created the dm-constraints plugin for precisely this > functionality. Currently it will create some DB level constraints, but > the plan was to make it create code level constraints always, and then > DB level constraints if the storage engine supports it. That way > there's two levels of protection on the data. It's also really nice > for testing because if you forget and delete a parent before a child, > it will blow up and tell you. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/datamapper?hl=en -~----------~----~----~----~------~----~------~--~---
