Oleg, yeah that sounds like a good idea. I hadn't thought about that case.
Perhaps an argument to the association like :auto_constrain => true| false.. where it would default to true (I would want to do the safest thing possible as much as possible). I also think the :protect option should be the default when someone doesn't specify the :dependent constraint. I think it's rare in most apps that have data you care about to allow orphan records (where the parent is deleted but not the children). I mean, you wouldn't be using dm-constraints if that wasn't the case so it's the safest default :) Also, we're trying to steer clear of "databasey" terms, so perhaps this would be better: :protect|:destroy|:destroy!|:set_nil|:skip # or maybe :nillify ? I dunno, what do you think? The :destroy! convention is because in other places within DM we use the destroy! to indicate we are bypassing any hooks and just deleting the data directly. We don't even instantiate the resource, we just kill it. Dan (dkubb) On Nov 8, 6:52 pm, Oleg Andreev <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
