the issue is that the mysql dialect assumes cursor.lastrowid applies
to the first primary key column in the table. Build your tables like
this and it works:
table_b = Table('table_b', metadata,
Column('id', Integer(), nullable=False, primary_key=True),
Column('a_id', Integer(), nullable=False, primary_key=True),
Column('name', String(20), nullable=True),
ForeignKeyConstraint(['a_id'], ['table_a.id'],ondelete='CASCADE'),
)
table_c = Table('table_c', metadata,
Column('id', Integer(), primary_key=True),
Column('a_id', Integer(), nullable=False, primary_key=True),
Column('b_id', Integer(), nullable=False, primary_key=True),
Column('name', String(20), nullable=True),
ForeignKeyConstraint(['a_id', 'b_id'],
['table_b.a_id','table_b.id'], ondelete='CASCADE'),
)
I will investigate a way such that the dialect more intelligently
selects the primary key column which recieves AUTOINCREMENT behavior.
On Jul 30, 2009, at 5:50 PM, Christian Schwanke wrote:
>
> Thanks for your quick answer. However, I still don't understand why
> another relation is necessary.
>
>> relation ItemC.b takes care of the assignment of table_c.b_id, but
>> there
>> is nothing here for SQLA to know about table_c.a_id.
>
> table_c.a_id is *not* the problem - table_c.b_id is not assigned and
> that value has nothing to do with itemA at all.
> In my opinion the ForeignKeyConstraint on Table C contains all
> information SQLA should need in order to populate the primary key of
> C. The relation from B->A works essentially the same as C->B with the
> only difference that B has one autoincremented PK column and one
> assigned from A, while C has one autoinc column and two values
> assigned from B.
> In both cases, a FK constraint is present, specifying the relation
> between the tables. Looking at the FK constraints, SQLA should be able
> to determine the order in which the models are to be persisted (A->B-
>> C) and then assign all autoincremented values correctly.
>
>> You need another relation() on ItemC which expresses this, and you
>> need to assign itemA1 to
>> ItemC explicitly, independently of the ItemB stuff.
>
> This might work, but this doesn't make sense to me, because ItemC
> shouldn't really have to know about itemA because the PrimaryKey of C
> only depends on the primarykey of B. The fact, that the PK on B is in
> turn dependent on A should not be a factor.
>
> In fact, I modified the testcase and removed a_id from table_c
> altogether - The autoincremented id of itemB is still not set on the
> C-
> Model, so I'm still thinking this is a bug with nested relations - the
> fact that the primary key is composed of multiple columns does not
> seem to contribute to the problem.
>
>
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
