On Dec 4, 2007, at 12:34 PM, Kapil Thangavelu wrote:
> i've attached an example, where a class constructor setups a default > value on a relation field, in the constructor, the app code latter > explicitly sets the fk attribute on the class, but sa ignores this > value, and in the flushing process sets it be the value of the orm > field, so that it 'magically' becomes none even though it was > explicitly set, which throws an integrity constraint violation since > the fk is setup to be not null. > > not sure if this a bug or just a warning on sa usage patterns.. > its the self.status =None. its a contradiction for you to explicitly set "status" to None yet have the status_id set to a value. if you leave self.status alone, the status_id will remain set. i dont think this is particularly magical, its the relation() that you've explicitly created just doing its job. you can also expire the 'status' attribute via s.expire(m, ['status']) which will prevent the value from affecting the flush. its possible that sqlalchemy could look at the status_id attribute and see that it was modified, therefore leaving it alone, but this would allow contradicting attribute values which definitely would lead to deeper issues. i would almost think that if you change both status and status_id in an incompatible way it should raise an error. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
