well, yet another, wellcome to the pack... have a look at (my) dbcook. http://dbcook.sourceforge.net/readme either on pypi or direct svn co https://dbcook.svn.sourceforge.net/svnroot/dbcook/trunk or even more things at https://dbcook.svn.sourceforge.net/svnroot/dbcook
my opinion on validation is: a) validation and default_values / auto-setup are same thing - or different sides of one thing b) there are many levels of validation, with their own semantics, at different points in a workflow, and they _can not_ be expressed all at same place in same way, although most of the job can be done in one. now on your question, i tell you what i have as i've asked it some time ago here. i have a (non-mandatory) db-manager class that takes care of anything runtime db-related (engine, db, sessions, etc), and that one has a method .save_all( somenamespace_or_list_here). Which serves as "these things should go into db _now_" There i check if the objects have a .pre_save() method/s and eventualy call that one. Then, on the app-level objects, i have a .validate() and the .pre_save() which calls that one, as well as other things. here the workflow: - 1) user interaction starts (e.g. some dialog open etc) - 2) for immediate interaction (field-by-field, not-whole form), user changes this or that field, and some validations happen (one field or multiple fields, think a,b,c where a+b=c) - 3) end of user-interaction (e.g. OK/save button pressed) - 4) dialog/form level validation, can throw or return error-list or whatever - 5) all primary-level things changed between 1) and 4) go into .save_all - 6) it will execute the pre_save which will execute the object's.validate, and that can throw exceptions/return error-list/whatever - 7) do session.add() and session.flush() the point of this hook into the workflow is before sa.session comes into play. it works well but is not solving everything: * plus: u can add more objects to be saved or unchange/refuse objects or whatever - as this is before sa.session knows about them * minus: relations/references that are indirectly pulled into being saved, are not known to it and their pre_save/validate will not be called. * todo it, one can start walking around properties and check this and that but i dont do it (yet?) as this seems to duplicate session.* stuff. * or, move certain validations on different/deeper/narrower level There is another level of hook: a SessionExtension.before_flush() if u want, check a post "sessionExtension" by me from 12.may. * pluses: * u know what is modified and whats not * most (relational) dependencies are available but not all * minus: * u cannot change flush-plan, i.e. any structural changes done here will be left for next flush() - no adding objects or changing unchanged objects or unchanging changed objects and there is another point, mapperExtension/before_insert: * plus: * everything is there, foreign keys, references, anything * less things can be changed plus two more, outside of ORM: column-defaults/onupdate and inside-db-triggers or similar. so there are, what, 5-6 levels of hooks (inside user-interaction, after interaction before session - dialog scope, after-that - "what's saved" scope, before session.flush, before mapper.insert, before column.insert, trigger), and each one has its pluses and minuses. frankly, i havenot decided what to choose, still experimenting - will probably expose most of them as obj-level-hooks and let the users (which is so far only me team) decide. for example, i hit a problem with missing timestamps on related indirect items, and first solved it by manualy adding a mapper.before_insert hook calling same .pre_save, but then moved them further into column-defaults. ciao and have fun svilen On Saturday 12 July 2008 16:40:12 kindly wrote: > I have just started working on "another" kind of declarative layer > for SQLalchemy. Infact it is more like a domain specific language > for setting up basic form orientated databases for small charities > in order to provide viable alternative to Access for simple > information storage needs. The details of which I will not go into > now. > > My approach for validation is to have a function within each ORM > object, say obj.validate(). This goes off checks external metadata > (not sqlalchemy metadata) and runs the checks on that object using > formencode. If the form is a different to the database fields (say > composite inputs) the object holds the inputs and can validate both > these and the actual parameter they create (useful for unique > validations). I will not use the full power of formencode scemas > but will use them for composite validations within a form. I will > then collect all the validation errors from all the validators and > return them to the controller. > > I have overwritten the Sessions session.add method to perform these > checks so as not flush until there are no validation errors, and if > there are, return a dict of the errors for the controller. > > I just want to know if anyone can think of any reasons that this is > a terrible idea, based on a clearer understanding of sqlalchemy orm > objects then myself? as to me unless something particuarly > mysterious happens to the objects, or the session will break in > some way if you override add, it should be fine. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
