> On Dec 9, 2014, at 10:18 AM, Martin Marrese <marr...@gmail.com> wrote:
> 
> Hi, 
> 
> I have been doing some tests to solve a requirement given in where an object 
> must check some of the values on its attributes before an insert or an update 
> gets triggered into the db.
> 
> Did some tests with validates decorator and because some of the fields 
> require other fields to be set before, cannot use it. Solved that using 
> events and before_insert/before_update events.

> Listening for events has the disadvantage that all created instances will be 
> checked, no matter if they were added or not to the session.

before_insert/before_update only applies to objects that are present in the 
session, and only those that are actually subject to an INSERT or UPDATE.   
objects that were not added to the session are not subject to these events.   
It is typically my last choice for business-level validation as it is the least 
well suited to this task.

> 
> Beyond that, I also have to make a field validate to its previous value, and 
> cannot find a way to do this without making other queries.

previous values are available using the history API at 
http://docs.sqlalchemy.org/en/rel_0_9/orm/session.html#attribute-and-state-management-utilities
 
<http://docs.sqlalchemy.org/en/rel_0_9/orm/session.html#attribute-and-state-management-utilities>
 as well as through the inspection interface using 
http://docs.sqlalchemy.org/en/rel_0_9/orm/internals.html#sqlalchemy.orm.state.AttributeState.history:
 
<http://docs.sqlalchemy.org/en/rel_0_9/orm/internals.html#sqlalchemy.orm.state.AttributeState.history:>

inspect(myobject).attrs[‘some_attribute’].history



> In my case is a field called state_id that is a foreign key to another table 
> and who has a strict flow that must follow, so when updated it must check for 
> the previous value to see if the new value is allowed.

for state transitions I’d recommend building out your objects to perform these 
operations correctly, using setter methods and/or the @validates event.   When 
you state that “some of the fields require other fields to be set before”, 
well, that’s part of the required state.   Apply the @validates event to those 
other fields as well, and have all of the validators coordinate such that they 
only perform the final check when all conditions are present.      The ORM and 
the history API may provide an “easy out” and save you the effort of building 
this system yourself for simplistic cases, but note that the ORM/attribute 
history API is designed for the task of persistence only, not complex state 
transitions and business case validation.


-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.

Reply via email to