sqlalchemy-tickets — trac tickets and updates forwarded to this list

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-----------------------------------+----------------------------------
      Reporter:  tisdall           |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  low               |  Milestone:  0.9.xx
     Component:  orm               |   Severity:  minor - half an hour
    Resolution:  worksforme        |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------

Comment (by tisdall):

 Thank you!

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:9>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-----------------------------------+----------------------------------
      Reporter:  tisdall           |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  low               |  Milestone:  0.9.xx
     Component:  orm               |   Severity:  minor - half an hour
    Resolution:  worksforme        |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------

Comment (by zzzeek):

 safest bet is to stick with _creation_order as above for now, sort by that
 as you pull off of mapper.attrs.   Since there's really no other thing you
 can "order by" on a Python class.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:8>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2916: possible numeric regression on 0.9.1

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

#2916: possible numeric regression on 0.9.1
---------------------------+-------------------------------
      Reporter:  zzzeek    |      Owner:
          Type:  defect    |     Status:  new
      Priority:  highest   |  Milestone:  0.9.xx
     Component:  mssql     |   Severity:  major - 1-3 hours
    Resolution:            |   Keywords:
Progress State:  in queue  |
---------------------------+-------------------------------

Comment (by zzzeek):

 will try this out but waiting from the user if they meant the
 "coefficient" column, not "conversation"

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2916#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2916: possible numeric regression on 0.9.1

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

#2916: possible numeric regression on 0.9.1
---------------------+------------------------------------
 Reporter:  zzzeek   |           Owner:
     Type:  defect   |          Status:  new
 Priority:  highest  |       Milestone:  0.9.xx
Component:  mssql    |        Severity:  major - 1-3 hours
 Keywords:           |  Progress State:  in queue
---------------------+------------------------------------
 {{{
 test env: sql server 2005 and pyodbc 3.0.7 and freetds 0.91, on debian 8.0
 product env: sql server 2005 and pyodbc 3.0.7 and native client 10.0, on
 windows 2003
 above two env  is the same behavior with 0.9.1, always return decimal
 object for float type

 follow is part data model:

 from sqlalchemy.ext.declarative import declarative_base
 from sqlalchemy.schema import Column,
 from sqlalchemy.types import SmallInteger, Integer, Float
 from sqlalchemy.types import String

 Base = declarative_base()

 class Unit(Base):
     __tablename__ = 't_MeasureUnit'

     id = Column('FMeasureUnitID', Integer, autoincrement=False,
 primary_key=True)
     name = Column('FName', String(80), nullable=False)
     number = Column('FNumber', String(30), nullable=False)
     short_number = Column('FShortNumber', String(30))
     conversation = Column('FConversation', Integer, server_default='(1)')
     coefficient = Column('FCoefficient', Float, nullable=False,
 server_default='(1)')
     deleted = Column('FDeleted', SmallInteger, nullable=False,
 server_default='(0)')

 with 0.8.4, conversation column return python float object, upgrade to 0.9
 or 0.9.1 all Float column always return decimal object.
 my project and the data model has been running for over two years, pass
 two year with 0.7 and 0.8 no problem. my project not need to use decimal,
 float precision  is sufficient.
 }}}

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2916>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-----------------------------------+----------------------------------
      Reporter:  tisdall           |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  low               |  Milestone:  0.9.xx
     Component:  orm               |   Severity:  minor - half an hour
    Resolution:  worksforme        |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------

Comment (by tisdall):

 The reason is for [https://github.com/tisdall/ColanderAlchemy
 ColanderAlchemy].  Colander schemas have a particular order and are used
 to generate HTML forms with Deform in that same order.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:7>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2915: Different database backend raise different exceptions on not null constraint violations

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

#2915: Different database backend raise different exceptions on not null
constraint violations
-----------------------------------+------------------------------------
      Reporter:  guidow            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:
     Component:  engine            |   Severity:  no triage selected yet
    Resolution:  wontfix           |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+------------------------------------

Comment (by zzzeek):

 as it is, the backends know how to detect exactly *one* type of error
 scenario, that of an exception that indicates the database connection is
 no longer connected.  just that alone is a feature we are constantly
 getting new tickets for as new database conditions are discovered.   Look
 at the awkwardness of the MySQL, Postgresql and Oracle backends for
 example:

 https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/dialects/postgresql/psycopg2.py#L460

 https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/dialects/mysql/base.py#L2132

 https://github.com/zzzeek/sqlalchemy/blob/master/lib/sqlalchemy/dialects/oracle/cx_oracle.py#L813

 note that two of those routines are not only database specific, but
 *DBAPI* specific - messages are sent out from various C drivers which
 aren't the same as those sent out from other interpretation layers.
 Multiply that by the number of things that can go wrong and I'm hoping the
 infeasibility of the task is apparent.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2915#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2915: Different database backend raise different exceptions on not null constraint violations

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

#2915: Different database backend raise different exceptions on not null
constraint violations
-----------------------------------+------------------------------------
      Reporter:  guidow            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:
     Component:  engine            |   Severity:  no triage selected yet
    Resolution:  wontfix           |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+------------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => wontfix
 * status_field:  awaiting triage => completed/closed


Comment:

 unfortunately this is a situation of the DBAPI specification and is not
 within SQLAlchemy's power to fix - only if SQLAlchemy were to add massive
 translation layers for every exception possible raised by every database
 backend, which would be very error prone and make things a lot worse.   We
 propagate DBAPI exceptions as is (with additional information about
 context) in order to maximize transparency about what went wrong.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2915#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2915: Different database backend raise different exceptions on not null constraint violations

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

#2915: Different database backend raise different exceptions on not null
constraint violations
--------------------+-----------------------------------------
 Reporter:  guidow  |           Owner:  zzzeek
     Type:  defect  |          Status:  new
 Priority:  medium  |       Milestone:
Component:  engine  |        Severity:  no triage selected yet
 Keywords:          |  Progress State:  awaiting triage
--------------------+-----------------------------------------
 I noticed that different database backends may cause different exceptions
 to be raised when violating a not null constraint.

 Sqlite, for example, seems to raise IntegrityError, while MySQL with
 mysql-python raises OperationalError and postgresql with pg8000 raises
 ProgrammingError.

 This is a bit of a problem when developing software that is supposed to be
 backend-agnostic. You can still catch the exception by catching the parent
 class DatabaseError, but this is not helpful when you are trying to figure
 out what exactly went wrong.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2915>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2912: multiple table update with two columns having the same name

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

#2912: multiple table update with two columns having the same name
-----------------------------------+--------------------------------
      Reporter:  shnavid           |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  high              |  Milestone:  0.9.xx
     Component:  mysql             |   Severity:  major - 1-3 hours
    Resolution:  fixed             |   Keywords:  multi table update
Progress State:  completed/closed  |
-----------------------------------+--------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * component:  orm => mysql
 * resolution:   => fixed
 * status_field:  awaiting triage => completed/closed


Comment:

 rb9318c98637bbd5c1926772

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2912#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2910: simplify primary key reflection and support empty PKConstraint + arguments that gathers PK cols

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

#2910: simplify primary key reflection and support empty PKConstraint + arguments
that gathers PK cols
-----------------------------------+-------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  enhancement       |     Status:  closed
      Priority:  high              |  Milestone:  0.9.xx
     Component:  sql               |   Severity:  major - 1-3 hours
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * severity:  minor - half an hour => major - 1-3 hours
 * status_field:  needs tests => completed/closed


Comment:

 r49f1807f8f2acea5494fa77d217dce813a933147 - we are only doing a warning
 re: the column collection mismatch to avoid backwards incompatibility.


 r417aeaf1453c67130fb8f1a2bb21c38e6795ce25 contains an extra adjustment to
 restore ordering to the constraint.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2910#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-----------------------------------+----------------------------------
      Reporter:  tisdall           |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  low               |  Milestone:  0.9.xx
     Component:  orm               |   Severity:  minor - half an hour
    Resolution:  worksforme        |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------

Comment (by zzzeek):

 the order of columns when using Declarative is determined by the order in
 which each Column is constructed, since otherwise the ordering of items on
 a class in Python is unordered.  So there is actually significant logic in
 order to maintain this ordering within the Table object that's created.

 This ordering counter is also shared on relationship objects and such, but
 declarative does not pass the objects to the mapper in such a way that
 this ordering is maintained; nor does it specify column/relationship
 objects as individuals, instead the mapper maps the whole Table object at
 once, so there is no way right now that an "interleaved" pattern of plain
 columns/relationships can be produced using standard declarative, unless
 declarative re-implemented the mapper's usual job of iterating through
 table columns which is redundant.   the ordering logic thus far is only
 concerned with making sure column order on the Table is maintained, as
 this results in DDL passed to the database.

 probably the most expedient way to sort in object creation order is this:

 {{{
 from sqlalchemy import inspect
 from sqlalchemy.orm import ColumnProperty
 mapper = inspect(Person)

 def creation_order(obj):
     if isinstance(obj, ColumnProperty):
         return obj.columns[0]._creation_order
     else:
         return obj._creation_order

 mapper._props.sort(key=lambda k: creation_order(mapper._props[k]))
 }}}

 why exactly would it be important such that the order in which attributes
 are declared on a class be mirrored when inspecting the mapping?  This is
 not the case for Python builtins such as `dir()`.  The attributes on a
 Python class are not ordered.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:6>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-----------------------------------+----------------------------------
      Reporter:  tisdall           |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  low               |  Milestone:  0.9.xx
     Component:  orm               |   Severity:  minor - half an hour
    Resolution:  worksforme        |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------

Comment (by tisdall):

 yeah, I'm seeing the `attrs` is not maintaining the order that attributes
 are defined in the object.  I was looking through the code and thought
 that was the reason, but I'm wrong.

 Here's the object I'm defining:
 {{{
 #!python
 class Person(Base):
     __tablename__ = 'persons'

     id = Column(Integer, primary_key=True)
     name = Column(Unicode(128), nullable=False)
     surname = Column(Unicode(128), nullable=False)
     phones = relationship(Phone)
 }}}

 The order I consistently get back is
 {{{
 Person.phones
 Person.id
 Person.name
 Person.surname
 }}}

 When I'm expecting to get `Person.phones` at the end of the list.  Does
 the OrderedDict not maintain the order the attributes are defined in the
 class?

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:5>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-----------------------------------+----------------------------------
      Reporter:  tisdall           |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  low               |  Milestone:  0.9.xx
     Component:  orm               |   Severity:  minor - half an hour
    Resolution:  worksforme        |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+----------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => worksforme
 * status_field:  needs questions answered => completed/closed


Comment:

 this is tested already in test_inspect, added another test in
 r84b03137eb16b5e2a34e69.   I think we are OK here please reopen if you can
 illustrate ordering not being maintained.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:4>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-------------------------------------------+-------------------------------
      Reporter:  tisdall                   |      Owner:  zzzeek
          Type:  defect                    |     Status:  new
      Priority:  low                       |  Milestone:  0.9.xx
     Component:  orm                       |   Severity:  minor - half an
    Resolution:                            |  hour
Progress State:  needs questions answered  |   Keywords:
-------------------------------------------+-------------------------------
Changes (by zzzeek):

 * status_field:  in queue => needs questions answered


Comment:

 OK hold on.  `ImmutableProperties` is passed the data dictionary, it does
 *not* use any kind of dict on its own.    `.attrs` specifically invokes
 `util.ImmutableProperties(self._props)`, so it's ordered.

 Are you observing that `mapper.attrs` is not maintaining ordering?

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
---------------------------+----------------------------------
      Reporter:  tisdall   |      Owner:  zzzeek
          Type:  defect    |     Status:  new
      Priority:  low       |  Milestone:  0.9.xx
     Component:  orm       |   Severity:  minor - half an hour
    Resolution:            |   Keywords:
Progress State:  in queue  |
---------------------------+----------------------------------
Changes (by zzzeek):

 * status_field:  awaiting triage => in queue
 * component:  cextensions => orm
 * severity:  no triage selected yet => minor - half an hour
 * milestone:   => 0.9.xx


--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
----------------------------------+------------------------------------
      Reporter:  tisdall          |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  low              |  Milestone:
     Component:  cextensions      |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by tisdall):

 forgot to set the proper "Component" on the ticket, sorry.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[Sqlalchemy-tickets] [sqlalchemy] #2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order

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

#2914: sqlalchemy.orm.mapper.Mapper.attrs doesn't maintain order
-------------------------+-----------------------------------------
 Reporter:  tisdall      |           Owner:  zzzeek
     Type:  defect       |          Status:  new
 Priority:  low          |       Milestone:
Component:  cextensions  |        Severity:  no triage selected yet
 Keywords:               |  Progress State:  awaiting triage
-------------------------+-----------------------------------------
 `sqlalchemy.orm.mapper.Mapper.attrs` is an immutable wrapper around
 `sqlalchemy.orm.mapper.Mapper._props`.  However it uses
 `util.ImmutableProperties` which uses a regular `dict` as a backend and
 thus loses the order (`_props` is an OrderedDict).

 I think it should be changed to use something like:
 {{{
 #!python
 class ImmutableOrderedProperties(ImmutableContainer, OrderedProperties):
     """Provide immutable dict/object attribute to an underlying
 OrderedDict."""
 }}}

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2914>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2909: support MS ODBC for linux / Connection is busy with results for another command

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

#2909: support MS ODBC for linux / Connection is busy with results for another
command
-----------------------------------+-------------------------------
      Reporter:  tuomur            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  high              |  Milestone:  0.9.xx
     Component:  mssql             |   Severity:  major - 1-3 hours
    Resolution:  wontfix           |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => wontfix
 * status_field:  needs questions answered => completed/closed


Comment:

 OK, I have a feeling there's an ODBC driver setting regarding this
 behavior.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2909#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

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

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:  enhancement      |     Status:  new
      Priority:  medium           |  Milestone:
     Component:  schema           |   Severity:  no triage selected yet
    Resolution:                   |   Keywords:  tometadata
Progress State:  awaiting triage  |
----------------------------------+------------------------------------

Comment (by dtheodor):

 Ticket contains some mistakes, but I can't find a way to edit it:

 The original code should be

 {{{#!python
 m = Metadata(schema="shared")
 t = Table('t', m,
     Column('x', Integer))

 t1 = Table('t1', m,
     Column('t_x', Integer, ForeignKey('shared.t.x')),
     schema="schema1")

 m2 = Metadata()
 t1_copy = t1.tometadata(m2)

 t1_copy_schema2 = t1.tometadata(m2, schema="schema2")
 }}}

 Now `t1_copy.t_x` now references a column `schema1.t.x`, while
 `t1_copy_schema2.t_x` references a `schema2.t.x`, both of which are wrong.

 The proposed changed changes these results to `shared.t.x` and
 `schema2.t.x` respectively
 Replying to [ticket:2913 dtheodor]:
 > I think the behavior of Table.tometadata()'s copying of foreign keys is
 unexpected when it comes to copying foreign keys that reference tables in
 a schema different than the schema of the table being copied. This
 occurred to me in the discussion at
 https://groups.google.com/forum/#!topic/sqlalchemy-alembic/FA8wpmPJc7U
 >
 > For instance, when we  have two tables in different schemas
 > {{{#!python
 > m = Metadata()
 > t = Table('t', m,
 >     Column('x', Integer, ForeignKey('a.x')),
 >     schema="shared")
 >
 > t1 = Table('t1', m,
 >     Column('t_x', Integer, ForeignKey('shared.t.x')),
 >     schema="schema1")
 >
 > m2 = Metadata()
 > t1_copy = t1.tometadata(m2)
 >
 > t1_copy_schema2 = t1.tometadata(m2, schema="schema2")
 > }}}
 >
 > After this, `t1_copy.t_x` now references a column `schema1.t.x`, while
 `t1_copy_schema2.t_x` references a `schema2.t.x`, both of which are wrong.
 >
 > I think the correct behavior would be to only modify the schema of the
 foreign key's reference '''only if''' that schema is the same as the
 table's original schema. To be more precise:
 >
 > 1) If referenced_schema == previous_schema, update as is the current
 behavior
 > 2) If referenced_schema != previous_schema, then need to decide how/if
 to update the referenced column's schema. I would leave the schema
 unchanged, or pass a dictionary that maps previous schemas to the new
 ones.
 >
 > In code, something like this:
 >
 > {{{#!python
 > def tometadata(self, metadata, schema=RETAIN_SCHEMA,
 fk_schema_replace={}):
 >     # ....
 >     #section on constraints copy
 >         previous_schema = self.schema
 >         #by default, modify FK's schema if the schema is the same as the
 table's
 >         if previous_schema not in fk_schema_replace:
 >             fk_schema_replace.update({previous_schema: schema})
 >         for c in self.constraints:
 >             constraint_schema = schema
 >             if isinstance(c, ForeignKeyConstraint):
 >                 fk_schema = c.elements[0].column.table.schema
 >                 constraint_schema = fk_schema_replace.get(fk_schema)
 >                 #if a replacement is found it is used, otherwise schema
 is unchanged
 >             table.append_constraint(c.copy(schema=constraint_schema,
 target_table=table))
 > }}}
 >
 >
 > With this change, I can do
 > {{{#!python
 > t1_copy = t1.tometadata(m2)
 >
 > t1_copy_schema2 = t1.tometadata(m2, schema="schema2",
 fk_schema_replace={'shared':'schema2'})
 > }}}
 >
 > Then `t1_copy.t_x` will reference `shared.t.x`, while
 `t1_copy_schema2.t_x` will reference `schema2.t.x`
 >
 > Thoughts?

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2913#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

[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:  enhancement  |          Status:  new
 Priority:  medium       |       Milestone:
Component:  schema       |        Severity:  no triage selected yet
 Keywords:  tometadata   |  Progress State:  awaiting triage
-------------------------+-----------------------------------------
 I think the behavior of Table.tometadata()'s copying of foreign keys is
 unexpected when it comes to copying foreign keys that reference tables in
 a schema different than the schema of the table being copied. This
 occurred to me in the discussion at
 https://groups.google.com/forum/#!topic/sqlalchemy-alembic/FA8wpmPJc7U

 For instance, when we  have two tables in different schemas
 {{{#!python
 m = Metadata()
 t = Table('t', m,
     Column('x', Integer, ForeignKey('a.x')),
     schema="shared")

 t1 = Table('t1', m,
     Column('t_x', Integer, ForeignKey('shared.t.x')),
     schema="schema1")

 m2 = Metadata()
 t1_copy = t1.tometadata(m2)

 t1_copy_schema2 = t1.tometadata(m2, schema="schema2")
 }}}

 After this, `t1_copy.t_x` now references a column `schema1.t.x`, while
 `t1_copy_schema2.t_x` references a `schema2.t.x`, both of which are wrong.

 I think the correct behavior would be to only modify the schema of the
 foreign key's reference '''only if''' that schema is the same as the
 table's original schema. To be more precise:

 1) If referenced_schema == previous_schema, update as is the current
 behavior
 2) If referenced_schema != previous_schema, then need to decide how/if to
 update the referenced column's schema. I would leave the schema unchanged,
 or pass a dictionary that maps previous schemas to the new ones.

 In code, something like this:

 {{{#!python
 def tometadata(self, metadata, schema=RETAIN_SCHEMA,
 fk_schema_replace={}):
     # ....
     #section on constraints copy
         previous_schema = self.schema
         #by default, modify FK's schema if the schema is the same as the
 table's
         if previous_schema not in fk_schema_replace:
             fk_schema_replace.update({previous_schema: schema})
         for c in self.constraints:
             constraint_schema = schema
             if isinstance(c, ForeignKeyConstraint):
                 fk_schema = c.elements[0].column.table.schema
                 constraint_schema = fk_schema_replace.get(fk_schema)
                 #if a replacement is found it is used, otherwise schema is
 unchanged
             table.append_constraint(c.copy(schema=constraint_schema,
 target_table=table))
 }}}


 With this change, I can do
 {{{#!python
 t1_copy = t1.tometadata(m2)

 t1_copy_schema2 = t1.tometadata(m2, schema="schema2",
 fk_schema_replace={'shared':'schema2'})
 }}}

 Then `t1_copy.t_x` will reference `shared.t.x`, while
 `t1_copy_schema2.t_x` will reference `schema2.t.x`

 Thoughts?

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2913>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2866: create kwarg registration system for dialect kwargs, build into _valdidate_dialect_kwargs

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

#2866: create kwarg registration system for dialect kwargs, build into
_valdidate_dialect_kwargs
-----------------------------------+-------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:  0.9.xx
     Component:  schema            |   Severity:  major - 1-3 hours
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * resolution:   => fixed
 * status_field:  in queue => completed/closed


Comment:

 r1af8e2491dcbed723d2cdafd44f

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2866#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2912: multiple table update with two columns having the same name

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

#2912: multiple table update with two columns having the same name
----------------------------------+--------------------------------
      Reporter:  shnavid          |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  high             |  Milestone:  0.9.xx
     Component:  orm              |   Severity:  major - 1-3 hours
    Resolution:                   |   Keywords:  multi table update
Progress State:  awaiting triage  |
----------------------------------+--------------------------------

Comment (by zzzeek):

 work in progress in the ticket_2912 branch.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2912#comment:2>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2911: rework of unicode conversion, re: "conditional" as well as cx_oracle

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

#2911: rework of unicode conversion, re: "conditional" as well as cx_oracle
-----------------------------------+-------------------------------
      Reporter:  zzzeek            |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  high              |  Milestone:  0.9.xx
     Component:  oracle            |   Severity:  major - 1-3 hours
    Resolution:  fixed             |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+-------------------------------
Changes (by zzzeek):

 * status:  new => closed
 * component:  cextensions => oracle
 * resolution:   => fixed
 * status_field:  in progress => completed/closed


Comment:

 r882f615c68cd2d244a8d2cf480

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2911#comment:3>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python

Re: [Sqlalchemy-tickets] [sqlalchemy] #2912: multiple table update with two columns having the same name

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

#2912: multiple table update with two columns having the same name
----------------------------------+--------------------------------
      Reporter:  shnavid          |      Owner:  zzzeek
          Type:  defect           |     Status:  new
      Priority:  high             |  Milestone:  0.9.xx
     Component:  orm              |   Severity:  major - 1-3 hours
    Resolution:                   |   Keywords:  multi table update
Progress State:  awaiting triage  |
----------------------------------+--------------------------------
Changes (by zzzeek):

 * priority:  medium => high
 * severity:  no triage selected yet => major - 1-3 hours
 * milestone:   => 0.9.xx


--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2912#comment:1>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python