This looks like a good solution. I'll need some time to provide a test
case, however.
If the change breaks existing code, how are cross-schema references
supposed to be handled?
Best regards
Klaus
On 18 Jun., 21:54, Michael Bayer <[EMAIL PROTECTED]> wrote:
> On Jun 18, 2007, at 4:25 AM, [EMAIL PROTECTED] wrote:
>
>
>
> > In my first experiments with elixir I noticed that sqlalchemy doesn't
> > handle foreign keys correctly on autoloaded tables. This has to to
> > with schema handling in the postgresql driver. A foreign key
> > referencing a table in the public schema from "outside" gets the table
> > name without the schema part and thus locates the table in its own
> > schema. I've appended a trivial fix below.
>
> im afraid this patch breaks several postgres reflection unit tests,
> since the "schema" attribute of Table is assumed to be of the default
> schema if not present. by making it present here, it fails to locate
> tables within its own metadata. i found when trying to create the
> test case for this issue it required explicitly stating the default
> schema name as the "schema" of the "inside" table. that is also a bug.
>
> the patch that fixes the all issues for the test I was able to create
> is:
>
> Index: lib/sqlalchemy/schema.py
> ===================================================================
> --- lib/sqlalchemy/schema.py (revision 2742)
> +++ lib/sqlalchemy/schema.py (working copy)
> @@ -701,7 +701,7 @@
> raise exceptions.ArgumentError("Invalid foreign
> key column specification: " + self._colspec)
> if m.group(3) is None:
> (tname, colname) = m.group(1, 2)
> - schema = parenttable.schema
> + schema = None
> else:
> (schema,tname,colname) = m.group(1,2,3)
> table = Table(tname, parenttable.metadata,
> mustexist=True, schema=schema)
>
> meaning, if you say ForeignKey("sometable.somecolumn") for a
> particular Column, the "schema" is assumed to be the "default"
> schema, not the "schema" specified for the Table which contains the
> ForeignKey object. this means creating a ForeignKey between two
> tables A and B, both with schema="myschema", would have to look like
> ForeignKey("myschema.a.somecol"), even though both tables are in the
> same "myschema" schema. Im OK with that but not sure how disruptive
> this change would be.
>
> if you can provide a test case illustrating your scenario (using
> Table/MetaData/Engine objects only; no elixir classes please), that
> would help greatly.
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
