Re: [Sqlalchemy-tickets] [sqlalchemy] #2913: Table.tometadata() foreign key copying behavior with d
Brought to you by:
zzzeek
|
From: sqlalchemy <mi...@zz...> - 2014-01-19 21:17:43
|
#2913: Table.tometadata() foreign key copying behavior with different schemas
---------------------------+-------------------------------
Reporter: dtheodor | Owner: zzzeek
Type: defect | Status: new
Priority: high | Milestone: 0.9.xx
Component: schema | Severity: major - 1-3 hours
Resolution: | Keywords: tometadata
Progress State: in queue |
---------------------------+-------------------------------
Changes (by zzzeek):
* priority: medium => high
* milestone: => 0.9.xx
* type: enhancement => defect
* severity: no triage selected yet => major - 1-3 hours
* status_field: awaiting triage => in queue
Comment:
yeah I had thought it already worked that way in that it wouldn't change
the schema of a referenced table with an already different schema, however
I think what i was likely remembering was logic that's in Postgresql's
reflection system specifically, to deal with the fact that PG won't
actually tell us the schema of an FK if that schema is in the current
search path.
the second thought is that the change here, while I think that's how it
should be, is not backwards compatible. So I'd want to check two things -
one is that it has always worked this way, e.g. the current system isn't
there for any particular reason, and two is that there's no tests for this
behavior right now, which would kind of imply we've just never
considered/supported this use. At some point we received a significant
patch that added the "schema" argument to MetaData in the first place, and
the patch went through a lot of review, so I'm surprised we never touched
this aspect of it at all.
--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2913#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python
|