I would see the sequel-model class having a base set of validations that are all performed on the code side. Then each database plugin can somehow override this base set to provide validation from the database. This would allow people to switch between databases without any changes to their code. As for if that is even possible with sequels current design I have no idea, I have yet to look very far into the code base. Not to mention some may not want to use the DB constraints so how would you deal with them?
You also bring up something I was not thinking about, how do you specify DB based constraints without causing problems when moving from one DB to another. Not to mention keeping you migrations straight with your current model. It seems to me that the constraints need to be somehow defined model side to keep all that model logic in one place. Meh, I don't have a good idea on how to solve that one. -Jeremy On Jan 15, 3:28 am, "Chris Farmiloe" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
