Up until 0.7, the discriminator column value is set within the flush process as a direct mapping of the object's type straight into the parameters passed to the INSERT, and can't be affected otherwise. 0.7 simplifies this behavior so that the discriminator is auto-populated at the time of __init__ for the object, then it's a regular attribute going forward.
Curious here is what kind of scheme you have that requires a manual setting of the discriminator. On Jan 1, 2011, at 9:52 PM, Eric Ongerth wrote: > I must be doing something wrong but can't find it. > > I'm doing some database refactoring and found a situation where I had > to set up a joined-table inheritance structure after the fact, with > some of the tables already populated. I created (successfully) a > script that got all of the primary and foreign keys right on all the > child tables and the parent table, and now I just need to correctly > populate the discriminator column on the parent table. > > Each row of the parent table is referenced by exactly one row from one > of the six child tables. So i'm iterating through all child objects > (yes, doing this via the sa ORM) and setting the value of the > discriminator appropriately. Then I commit the Session. Afterward, I > go and look at the parent table directly using pgAdmin and I see that > the new values in the discriminator column were not saved. That's > strange because I didn't get an error either, nor am I doing anything > that would mask an error. > > So I thought maybe the discriminator column on the parent table in a > joined-table inheritance scenario is just not watched by the Session / > UOW. I thought maybe it assumes that this column would only, > normally, be set during object instantiation and would typically not > change for the lifetime of the object and its associated database > rows. So I tried manually dirtying the object using > instance_state(obj).modified=True before committing the Session. > Still no success, the new values don't get saved. > > Is going outside of the ORM the only way to get this done? I don't > mind doing so, but I'm just trying to understand better why my initial/ > intuitive approach didn't do the job. > > Perhaps code / testcase will be requested and if I really can't figure > this out I'll produce them, but it's really a pain in this case > because it's a transient situation as part of a refactoring... I'm not > looking forward to trying to create this once-only situation where I > created the whole of a joined-table inheritance setup without telling > sqlalchemy about it, then table by table altered the keys and mappers > until everything was in place. Normally I wouldn't operate like > this. Poor excuse, perhaps, but I'll stand by it for today. > > -- > 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.
