Oh, whoops. Also I figured out why my solution of deleting, making
transient, then re-adding appeared not to work. It actually did
work, I just had some dead rows in the parent table that needed to be
weeded out. Now I can stop with this refactoring / migration madness
and get back to
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