The capabilities of each database system vary so much here that I can't see it ever being a truly portable solution like the rest of Sequel. maybe if database specific plugins were created that could upgrade the validations with DB specific reinforcements.
ie. a sequel_postgres_constraints plugin.... would be nice to have a little more of the database power in our models... special filters to define triggers for instance. But handling these as plugins is the only way I think. /just thinking aloud On 15/01/2008, David Lee <[EMAIL PROTECTED]> wrote: > > > Hey Jeremy, > > Thanks for responding. > I was also thinking about validations that cannot be done database > side. > > Perhaps we can have different terminology for the two types of > validations. > > The currently popular AR style validates_xxx can remain in their > current functionality, and database side validations errors can be > caught in a different way: > > database_validates_uniqueness_of :name > # > database_validates_format_of :email > database_validates_length_of :x > database_validates_presence_of :age > database_validates_reference_to :posts > database_validates_constraint /boo/, :msg => "Oh no!" > ... > > The last line above can match any error that contains "boo" and is a > useful construct because constraints can be named in the database > side. > > The second to last line would catch errors caused from foreign-key > errors. > > How does this sound? > > > -- Chris Farmiloe web: www.oxdi.eu direct: 01273 782909 skype: chrisfarms --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
