Like I said (in pseudo-code):
User.after(:save) { |u| raise RecordInvalid.new(u.errors) if
u.errors.size > 0 }
With a bit more magic you could abstract that out to Resources in
general as well. Like I said, almost too small for a plugin.
The name of the method is a bit of food for thought, but I'm not sure
it's worth pursuing. You could make the same argument for sending
emails, but calling #send! isn't going to guarantee delivery either.
Some IO is guaranteed, some isn't. I'd just lump O/RM persistence into
the latter.
As far as exceptions, it's just their nature. Back-tracking the call-
stack and gathering the method names, files and line-numbers is just
going to be an inherently expensive thing to do since it's pure
overhead. It's not a fixable problem. It's a no code is faster than no
code problem.
speaking-from-ignorance-and-semi-educated-guessing: The best you could
do is hide the expense by recording the trace information up-front,
but that just means you pay the cost everywhere, not that you've
really made exceptions all that much faster. /speaking-from-ignorance-
and-semi-educated-guessing
(If someone can prove me wrong I'd be interested in learning more
myself so feel free ;-) )
If you want "jump-to-label" behaviour (which is all that's been
consistently described), then use throw/catch.
-Sam
On Nov 28, 9:21 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
