On 9/8/06, Michael Bayer <[EMAIL PROTECTED]> wrote:
Thanks for the quick response!
This makes perfect sense. I've read the FAQ, but for some reason it apparently didn't sink in. I think I was stuck in a rut thinking that it was a FK problem, not a PK problem.
It might be nice if SA complained about modified PKs. It sure would've saved me a lot of time. :) Of course, it may be undesirable or impractical for reasons I'm not aware of.
you've found a slightly confusing example that basically is answered by
issue #1 on the SQLAlchemy FAQ at http://www.sqlalchemy.org/trac/wiki/FAQ
Thanks for the quick response!
This makes perfect sense. I've read the FAQ, but for some reason it apparently didn't sink in. I think I was stuck in a rut thinking that it was a FK problem, not a PK problem.
It might be nice if SA complained about modified PKs. It sure would've saved me a lot of time. :) Of course, it may be undesirable or impractical for reasons I'm not aware of.
.
SA's mapper works from the assumption of immutable primary keys (however,
like the faq says, you can change primary keys if you want, just SA's ORM
needs its hand held through such a process since it doesnt know how to
"flip the identity" of an instance in the session). since moving the
email address from one user to the other would require a change of primary
key within a single object instance, the use case youve defined is not
handled within the flush process. adding "identity-changing" detection
and "update pk" capability to the flush process would be pretty
complicated and probably has ramifications id rather not get into,
compared to alot of other higher priority items in trac.
even with your triple-PK-column table, the mapper setup can override the
erroneous schema as follows:
mapper(Email, self.email_addresses_table ,
primary_key=[self.email_addresses_table.c.email_address])
Gary Bernhardt wrote:
> I only started learning SQLAlchemy a few days ago, so I apologize in
> advance
> if I'm just confused. :)
>
> I've been thinking that I just didn't understand SQLAlchemy, but I now
> think
> I might be running into a nasty bug. I've generated two simple tests
> (attached) that show the problem (one passes; the other fails). Their
> only
> difference is in their schemas. I think that the difference should be
> irrelevant to the tests, but it's not.
>
> I define two tables, 'people' and 'email_addresses'. Here's the schema
> for
> the test that passes:
>
> self.people_table = Table('people', self.metadata,
> Column('first_name', String, primary_key=True),
> Column('last_name', String, primary_key=True))
>
> self.email_addresses_table = Table('email_addresses',
> self.metadata,
> Column('person_first_name', String),
> Column('person_last_name', String),
> Column('email_address', String, primary_key=True),
> ForeignKeyConstraint(['person_first_name',
> 'person_last_name'],
> ['people.first_name',
> 'people.last_name']))
>
> The actual test creates two people, one with an address and one without.
> It
> then moves the address from one person to the other, and verifies that it
> was moved. For the above schema, this works. Here's what SQLAlchemy does
> when the address is switched:
>
> [2006-09-08 16:39:26,644] [engine]: BEGIN
> [2006-09-08 16:39:26,682] [engine]: UPDATE email_addresses SET
> person_first_name=%(person_first_name)s WHERE
> email_addresses.email_address
> = %(email_addresses_email_address)s
> [2006-09-08 16:39:26,684] [engine]: {'email_addresses_email_address':
> '
> [EMAIL PROTECTED]', 'person_first_name': 'jane'}
> [2006-09-08 16:39:26,688] [engine]: COMMIT
>
> Now, here's the modified email_addresses table that makes it fail:
>
> self.email_addresses_table = Table('email_addresses',
> self.metadata,
> Column('person_first_name', String, primary_key=True),
> Column('person_last_name', String, primary_key=True),
> Column('email_address', String, primary_key=True),
> ForeignKeyConstraint(['person_first_name',
> 'person_last_name'],
> ['people.first_name',
> 'people.last_name']))
>
> The only difference here is that the primary key is now composed of
> (first_name, last_name, email_address). This doesn't really make sense
> semantically, but it illustrates the problem. With this schema, and the
> same test as before, the email address never actually gets moved from one
> user to the other:
>
> [2006-09-08 16:39:26,910] [engine]: BEGIN
> [2006-09-08 16:39:26,912] [engine]: COMMIT
>
> This is all with SQLAlchemy 0.2.8. Is this expected behavior, or a known
> bug, or am I just lucky?
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642_______________________________________________
> Sqlalchemy-users mailing list
> Sqlalchemy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
>
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Sqlalchemy-users mailing list Sqlalchemy-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
