It seems to me that #save is the wrong name for this method, then. When I say "save" or "create" I want it to actually record the object. If that doesn't happen, for any reason, then its a failure. I shouldn't have to ask afterwards if it was successful. I think of it like File in stdlib. If I tell it to write to a file, i dont have to ask afterwards if the write worked. If the method fails (write- protected, path doesn't exist...), it raises an exception. When I call Article.create, I expect it to be created. I shouldn't have to write code to double-check that it actually worked. If, for any reason, the #save doesn't actually save, its unexpected behavior. Everything else aside, this feels like the "correct" way. If exceptions are slow, examine why, and lets get it fixed in 1.9 or rubinius.
On Nov 28, 7:37 pm, Sam Smoot <[EMAIL PROTECTED]> wrote: > On Nov 28, 3:45 am, Alex Neth <[EMAIL PROTECTED]> wrote: > > > Regardless of the flow control debate, personally I consider the > > attempted saving of invalid data an exception, just as much as a file- > > not-found, end-of-file, or a database constraint violation (to which > > model validation is essentially equivalent). > > Obviously I don't agree. ;-) I buy into Fowler's argument whole- > heartedly that contextual-validation is important because programmers > are often overly strict in what's "valid" from a "just get it into the > database where I can work with it" perspective. > > It's also my experience that validation errors are routine, not > exceptional events, even when dealing with processes handling email > scraping or file parsing. > > > Invalid data is not a > > expected state, except perhaps arguably where dumb user input is > > involved. However DataMapper is an ORM, not a web framework, so it > > should not be designed primarily for user input. > > An O/RM is for _applications_ mainly IMO. I can't think of a lot of > cases where you aren't dealing with either user input, or input from > other processes (like a shipped file for processing) that don't come > from sources beyond your control. Internal WS/REST services are > probably the single exception that comes to mind, but I'm sure there's > more... > > > My more immediately point is that it is hard, if not impossible, to > > write correct code currently with DM. > > Now that's just hyperbole. Let me state, that off the top of my head, > a false save should only occur due to validation failures. If that's > not the case in your experience with DM definitely let me know because > that's the intent. > > We did go back and forth for awhile on wether saves with a clean (no > dirty attributes) object should return false, but turned out that was > just confusing and made for a difficult contract. > > > Can you suggest a pattern for > > handling validation that is correct? > > Paul's looks OK to me if you must have exceptions. > > > Let's take a simpler case of importing data from a file: > > >http://pastie.org/325959 > > > The basic problem is that there is no guarantee of what "false" means > > when returned from save. If you change the contract to be that false > > means there was a validation error, and state exceptions are thrown in > > any other instance of save failure, then I could write correct code. > > You've made the right assumptions on the contract. Like I said, if > #save returns false in cases other than validation failures, it's a > bug. > > Also, just a couple asides: > > 1. We decided on #save! skipping validations because it seemed > dangerous. Which fits much better with Ruby's core/stdlib than the > bang variant raising an error. > > 2. If you want to wrap up a variant of #save that raises on validation > errors, it should just be a simple :after hook. It's almost too > trivial for a whole plugin, but if you'd like to contribute a dm-is- > exceptional to dm-more the door's open. > > I'm not against people bending DM to their will. It's not going to be > all things to all people out of the box. It's going to be opinionated > in a Pythonic "One True Way" sort of way, just not in a Rails "You're > gonna suffer" sort of way hopefully. I anticipate anyone using DM will > maintain their own bag of tricks much like I'm sure we each have our > own core-extensions we include in every project. > > Sometimes I'm going to be a jerk about what does and doesn't get > included in DM proper. That doesn't mean you have to listen to me when > it comes to your own code. Your code is your code and while I might > have an opinion, it's not my work, it's not paying my bills, and you > need to do what's productive for you. I'll do my best to not make that > difficult. > > -Sam --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
