Wow, I didn't mean to uncork a can of worms on this one, I hope it got
as sorted out as it appears to be.

If I understand this correctly, I can expect to see a .save & .save!
methods appear in sequel_model, as well as changes to the validations
so that some validations are done based on the model, and some (like
uniqueness) are done based on the database's response.

Or is it more likely that I misread something and the validations are
going to start being based on the constraints the database is
performing, so that a save will attempt to update the database, which
will then throw the errors back to sequel_model and then let us end-
users deal with the sequel_model error?

I'm curious about this, as I don't have control over the database
designs for every database I have to interact with, and I certainly
can't vouch for the knowledge of those developers to leverage the
database appropriately.

-Joe

On Jan 15, 2:39 pm, jrmy <[EMAIL PROTECTED]> wrote:
> Now I understand what you are wanting. I agree with the others that it
> should be separated.
>
> -Jeremy
>
> On Jan 15, 11:53 am, David Lee <[EMAIL PROTECTED]> wrote:
>
> > Once again,
>
> > I'm not saying we should support constraints WITHIN the model.
>
> > Let me state my assumptions:
> > - validations exist to give users a nice error message to prevent
> > models from being saved, because otherwise, the database will raise a
> > nasty error
> > - validations do not validate 100%
> > - constraints validate 100%
> > - constraints cannot be defined in model, they must be defined when
> > defining tables
> > - preventing from within Ruby code & rollbacks from database both have
> > same results -- NO CHANGE.
> > - constraints raise ugly exceptions
> > - validations give nice error messages
>
> > So I'm suggesting that we should have a feature for models to RESCUE
> > (catch) the exception raised by the database connection and turn it
> > into a nice error message, like what validations do.
>
> > database_validates_constraint would not tell the database to actually
> > implement the constraint (because that's done when defining tables)
> > but would CATCH a constraint error thrown by the database and
> > translate that into a nice error message, like what validations do.
>
> > Example:
>
> > # table definition
>
> >   DB.create_table :items do
> >     ...
> >     constraint price_is_positive {:price > 0}
> >     ...
> >   end
>
> > # model
>
> >   database_validates_constraint 'price_is_positive', :msg => "Price
> > must be positive!"
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to