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
On Jan 2, 7:59 am, Michael Bayer mike...@zzzcomputing.com wrote:
Curious here is what kind of scheme you have that requires a manual setting
of the discriminator.
Forgive me, I tried to indicate that it doesn't, this is just a one-
time thing I have to do to get this database fixed up. Here's
On Jan 2, 2011, at 11:25 PM, Eric Ongerth wrote:
On Jan 2, 7:59 am, Michael Bayer mike...@zzzcomputing.com wrote:
Curious here is what kind of scheme you have that requires a manual setting
of the discriminator.
Forgive me, I tried to indicate that it doesn't, this is just a one-
time
Ah! I did it again. You may or may not remember I asked you a
different question yielding the same answer a couple of months ago!
I've got to put a stop to that trend.
To quote from your blog post:
===
In fact, while this table scheme is exactly joined table inheritance,
and we could certainly
So I tried my solution of deleting and then re-adding each object
(row) in question. Didn't work quite like that; instead I had to
delete, make_transient(), and then re-add. Still didn't quite work;
for rows that had sa relationships via FKs to other tables, in order
to avoid errors I had to
On Jan 3, 2011, at 2:02 AM, Eric Ongerth wrote:
So I tried my solution of deleting and then re-adding each object
(row) in question. Didn't work quite like that; instead I had to
delete, make_transient(), and then re-add. Still didn't quite work;
for rows that had sa relationships via FKs
Right, you made that clear before.
I was no longer talking about setting the discriminator column here in
0.6.5. I was talking about deleting, making transient, and then re-
adding all of the objects in question. And how this worked on some of
them but not all.
And your reasons for not
