Oleg, > > 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). > > :sql_constraints => true/false may make more sense, imho. > (or :builtin_constraints maybe?..)
I wouldn't want to name anything with "sql" because even though the primary target for this feature is DBs, its not inconceivable that other non-RDBMS engines could have something similar to foreign key constraints. The main reason for this flag is to ensure that the auto-migrate/ upgrade steps create the constraint. Given that I'd probably suggest naming it :auto_migrate_constraint or something similar. > There should be both :set_nil and :set_nil! > :set_nil instantiates the model and sets nil (running all hooks, > validations etc.) > :set_nil! runs bulk UPDATE SQL statement. That makes sense to me. > :set_nil should rollback current transaction in case of validation > failure. > :protected should rollback current transaction in case of non-empty > set of dependencies. I'm not sure the library code should automatically rollback a transaction directly. I'd probably rather have it throw an exception. If the code is inside a transaction block, and the developer doesn't catch the exception, when it bubbles up the stack the transaction will be rolled back. It's a subtle difference, but it puts the control of the exception handling in the hands of the developer. I'm wary of making an ORM that tries to be "too smart". > Therefore, in case of presence of any dependency to be updated/ > destroyed, #destroy method MUST start a new transaction (if it was not > started by the parent already). As stated above, I don't think DataMapper should handle too many exceptional cases automatically. I don't think destroying a resource should have any side effects like starting a transaction. > The good spec looks like this: > > DM::Constraints.default_constraints (attr_accessor, :protect by default) > DM::Constraints.sql_constraints (boolean attr_accessor, true by default) > > Note: I really need these globals to set default rules for the whole > app. In current application I would use the following: > DM::Constraints.default_constraints = :destroy > DM::Constraints.sql_constraints = false Currently DM doesn't have any global variables like this. You'll notice in dm-constraints that it mixes in some behavior into each adapter.. I would add constants to those files that you could override if need be. > Association options: > > :sql_constraints => true|false # default is > DM::Constraints.sql_constraints > :dependent => # default is DM::Constraints.default_constraints > :protect, # aborts transaction when set is not empty > :destroy, # safe destroy in a loop > :destroy!, # unsafe bulk delete > :set_nil, :nullify, :nillify, :nil, # safe update with > validations (all of these are aliases :-) > :set_nil!, :nullify!, :nillify!, :nil!, # unsafe bulk update > nil, :skip # skip foreign key > constraints (aliases) I would probably pick between :set_nil, :nullify and :nil. I think there should be one correct way to do something like this: both to keep the API clean and simple, and to keep the implementation as clean and concise as possible. > + automatic transactions with raising an error in case of invalid > record or a protected set. > + infinite loop detection (cyclic dependencies): when detected, > transaction is aborted. User should specify appropriate #destroy hooks > or specific dependency options to avoid such situation. I'm not entirely sure how you plan to approach the last point. > PS. I don't know much about built-in sql constraints, but it might be > interesting to make destroy/nullify/skip options affect these also. Oh, that's always the intention. With dm-constraints we want to make it so the code-level hooks are *always* set up. Then we want to make sure the DB level constraints match this whenever possible. Since our code-level hooks take care of deleting/nullification the DB's won't ever kick in, which is fine. We consider the DB constraints to be more like a safety net. Feel free to drop into #dm-hacking or #datamapper on IRC if you have any questions or concerns. I'm dkubb on IRC. Dan (dkubb) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
