Re: [Sqlalchemy-tickets] [sqlalchemy] #2913: Table.tometadata() foreign key copying behavior with different schemas

[sqlalchemy <mi...@zz...>]

#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