I'm not sure whether I understody your posting correctly. Now I've
checked out revision 2867 and nothing has changed, that is, I still
get the same exceptions.
Best regards
Klaus
On Jul 9, 9:44 am, klaus <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
