On Apr 10, 4:29 am, byrnejb <[email protected]> wrote: > 1. Rails ActiveRecord is used by an awful lot of people. I would > caution against introducing things into Sequel that look like AR > idioms but have completely different effects to avoid the resulting > confusion and errors that would plague people transitioning from AR to > Sequel. Sequel#save! == AR#save is not a good idea in my opinion.
Agreed. On the flip side, there is no reason to make repeat mistakes that AR has made for the sake of consistency. > 2. Setting flags to change method behaviour strikes me as, well, anti- > pattern to the object paradigm. Better I think would be methods named > something like '#save_and_continue' and '#save_or_fail' which disables > or enables #strict_modification for that specific call. You can think of the class level flags as setting defaults for all instances, which I don't consider an antipattern. The instance level flags aren't very often used, and while they are sort of an antipattern, they allow per level object customization that many libraries don't. For example, I don't believe AR allows you to change how save works, and I consider returning false for invalid saves a poor default (Sequel raises an exception by default, though lets you have the AR behavior as an option). Unfortunately, your separate method approach doesn't scale. There are already two flags related to saving, raise_on_save_failure and use_transactions. Adding this flag, which probably should be named check_modifications, would lead to 3 different flags, which would mean you would need 2^3 or 8 separate save methods to handle all of the flag combinations. A different approach is to add additional options to the save method, which currently accepts :changed, :transaction, and :validate. :transaction overrides the use_transactions flag if present, but there isn't a option to override the raise_on_save_failure flag (one could be added, but nobody has requested it). I tend to take a YAGNI approach here. Unless people are reporting pain using the API, there's no reason to complicate the internals to have a nicer API that nobody is using. Jeremy -- You received this message because you are subscribed to the Google Groups "sequel-talk" 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/sequel-talk?hl=en.
