On Apr 19, 2010, at 3:43 PM, Randy Syring wrote: > Mike, > > Thank you for your quick reply. > > If I understand correctly, after_flush() will get called after the SQL > is actually sent to the db server. If that is the case, then it is > too late for this validation as I would want the ability to test for > validation issues that would cause DB errors (i.e. NULL in non-NULL > fields, string lengths greater than the column size). > > However, I can do some testing with it.
if i understand correctly, if validation errors occur, then you'd raise an exception. Raising an exception inside of after_flush() would roll back the transaction, and assuming a database that supports transactions all the effects of the emitted SQL would be gone. Its roughly an equivalent stage as a database that uses deferred constraints, i.e. constraints that only take effect for newly modified data at the point of commit. The scheme that you're considering, using before_insert()/before_update(), would still emit SQL for everything type of object before the target object were handled. So there isn't too much difference - you're reliant upon transactional behavior in either case. > > On Apr 19, 3:31 pm, Michael Bayer <[email protected]> wrote: >> On Apr 19, 2010, at 3:25 PM, Randy Syring wrote: >> >> >> >> >> >>> * I would like default values to have been applied to the instance if >>> applicable before validation, i.e. i want to see the instance as a >>> mirror of what the flushed SQL will look like >>> * I would like to be able to have multiple models fail validation i.e. >>> I want to get details on as many errors as possible before raising an >>> exception >> >>> I was initially using before_insert and before_update on the mapper >>> extension and trying to "catch" the errors on those instances in the >>> session extension. However, before_flush() gets called before the >>> mapper extension's before_insert/update, so that didn't work. >> >>> So, Ideally, my work flow would look something like: >> >>> - before_insert/before_update called on each instance >>> -- instance.do_validation() called; any errors are stored on the >>> instance and the process continues >>> - I loop through the session looking for instances with validation >>> errors >>> -- if I find any, I throw a ValidationError exception >>> - SQL is actually flushed to the DB >> >>> I really am in over my head a bit in SA internals though, so feel free >>> to let me know if I am missing the big picture. >> >> did you try "after_flush()" ? the transaction hasn't been committed yet at >> that point. then you could whiz through the whole session and each object >> has everything fully, including DB-generated state. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sqlalchemy" 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 >> athttp://groups.google.com/group/sqlalchemy?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" 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/sqlalchemy?hl=en. > -- You received this message because you are subscribed to the Google Groups "sqlalchemy" 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/sqlalchemy?hl=en.
