Oops, obviously I made a mess of my program when pasting it into the
web form. Of course, there was a foreign key right from the beginning.
A whole line including a parenthesis and a comma dropped out:
> referer = Table("referer", metadata,
> Column("id", Integer, primary_key=True),
> Column("ref", Integer,
ForeignKey("subject.id")),
> schema="alt_schema")
Sorry for that.
The rest of your post seems to imply that the patch indeed does work.
I have to try that at home.
On 8 Jul., 23:24, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jul 8, 2007, at 11:38 AM, klaus wrote:
>
>
>
> > (Finally continuing this old thread.)
>
> > The suggested fix does not seem to work. Here is an example:
>
> > 1. To build the tables, create a schema test and run the following
> > code:
>
> cant reproduce. using trunk, with or without the patch, this script:
>
> from sqlalchemy import *
>
> metadata = BoundMetaData('postgres://scott:[EMAIL PROTECTED]/test',
> echo=True)
>
> subject = Table("subject", metadata,
> Column("id", Integer, primary_key=True),
> schema="public")
>
> referer = Table("referer", metadata,
> Column("id", Integer, primary_key=True),
> Column("ref", Integer),
> schema="alt_schema")
>
> metadata.create_all()
>
> produces:
>
> CREATE TABLE public.subject (
> id SERIAL NOT NULL,
> PRIMARY KEY (id)
> )
>
> CREATE TABLE alt_schema.referer (
> id SERIAL NOT NULL,
> ref INTEGER,
> PRIMARY KEY (id)
> )
>
>
>
> > The problem can be resolved by writing the ForeignKey more explicitly:
>
> > ForeignKey("public.subject.id")
>
> you should have the ForeignKey here since your mappers need it.
>
>
>
> > 2. Now try to use the tables with the following similar code: (The
> > main difference is autoload=True instead of the column definitions.)
>
> the issue here is "public" being the default schema combined with
> reflection of tables, and it cant create the join condition.
> Postgres system tables do not return the name "public" when
> reflecting the foreign key; therefore leave it blank. the "schema"
> argument is specifically for when using a schema that is *not* the
> default schema.
>
> the patch allows postgres reflection of this kind to work; the lack
> of a schema from the reflection sets "referer"'s foreign key to point
> to the "subject" table in the default schema.
>
> changeset 2866 commits this fix and two new unit tests testing
> combinations of PG tables between public and alt schemas and between
> two different alt schemas. the foreign key reflects correctly in both
> as well as an existing test that tests reflection across two tables
> in a single alt schema. for the example see:
> http://www.sqlalchemy.org/trac/changeset/2866
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
