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
-~----------~----~----~----~------~----~------~--~---
