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 mike...@zzzcomputing.com 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 sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
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 sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
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 sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
