On 09.11.2008, at 9:48, Dan Kubb (dkubb) wrote: > 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.
Oh, I got it! > 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. Okay. > 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". Yes, sure. >> 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. Just an example: if you don't have any transaction and you throw and exception somewhere in the middle of destroying associations, you will loose half of the data. More of that, since there should be before(:destroy) callback, not after(), your DB will come to a consistent state (sic!), so you probably won't even notice that! That's very dangerous, IMO. This implies to use initial transaction as a default decision. Which can be switched off, of course. > 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. Okay. However global accessors might be nicer than remove_const/ cons_set. It is not a hardcore "global variables programming", it's just a configuration interface. >> 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. :nullify is a well-known name from AR, but i'm comfortable with anything else too. Btw, :nil is a bad idea. It just one character away from nil which might be interpreted incorrectly. >> + 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. Me too =) That was just an idea. You can pass around a stack of models (e.g. in a Thread[:dm_constraints_stack]) to detect a moment when you come to repeated model. > 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. Sure. > Feel free to drop into #dm-hacking or #datamapper on IRC if you have > any questions or concerns. I'm dkubb on IRC. Okay. I'm oleganza. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
