delta/python-packages/sqlalchemy.git/doc, branch pr/232 github.com: zzzeek/sqlalchemy.git - changelog for #3621 fixes #3621 2016-02-02T22:29:42+00:00 Mike Bayer mike_mp@zzzcomputing.com 2016-02-02T22:29:42+00:00 9149fd062b8b5f4d84902b4581288ab991fd25ce 






- add changelog and migration notes for new Enum features,
2016-02-02T20:04:46+00:00

Mike Bayer
mike_mp@zzzcomputing.com

2016-02-02T18:00:19+00:00

df55695f8e99f0523795a7b9e9cb9babee2e00e1

fixes #3095, #3292
- reorganize enum constructor to again work with the MySQL
ENUM type
- add a new create_constraint flag to Enum to complement that of
Boolean
- reinstate the CHECK constraint tests for enum, these already
fail /skip against the MySQL backend
- simplify lookup rules in Enum, have them apply to all varieties
of Enum equally





fixes #3095, #3292
- reorganize enum constructor to again work with the MySQL
ENUM type
- add a new create_constraint flag to Enum to complement that of
Boolean
- reinstate the CHECK constraint tests for enum, these already
fail /skip against the MySQL backend
- simplify lookup rules in Enum, have them apply to all varieties
of Enum equally







- Fixed issue where inadvertent use of the Python ``__contains__``
2016-02-02T15:20:54+00:00

Mike Bayer
mike_mp@zzzcomputing.com

2016-02-02T15:15:40+00:00

e0a580b3d055a600afae61840058a5a30ef5fe74

override with a column expression (e.g. by using ``'x' in col``)
would cause an endless loop in the case of an ARRAY type, as Python
defers this to ``__getitem__`` access which never raises for this
type.  Overall, all use of ``__contains__`` now raises
NotImplementedError.
fixes #3642





override with a column expression (e.g. by using ``'x' in col``)
would cause an endless loop in the case of an ARRAY type, as Python
defers this to ``__getitem__`` access which never raises for this
type.  Overall, all use of ``__contains__`` now raises
NotImplementedError.
fixes #3642







- The ``sqlalchemy.dialects.postgres`` module, long deprecated, is
2016-01-29T16:44:58+00:00

Mike Bayer
mike_mp@zzzcomputing.com

2016-01-29T16:44:58+00:00

c59bf0007f0148b73c80a3d6b86d6c66ae0ab422

removed; this has emitted a warning for many years and projects
should be calling upon ``sqlalchemy.dialects.postgresql``.
Engine URLs of the form ``postgres://`` will still continue to function,
however.





removed; this has emitted a warning for many years and projects
should be calling upon ``sqlalchemy.dialects.postgresql``.
Engine URLs of the form ``postgres://`` will still continue to function,
however.







- happy new year
2016-01-29T16:20:22+00:00

Mike Bayer
mike_mp@zzzcomputing.com

2016-01-29T16:20:22+00:00

859379e2fcc4506d036700ba1eca4c0ae526a8ee












- revert the change first made in a6fe4dc, as we are now generalizing
2016-01-28T20:01:31+00:00

Mike Bayer
mike_mp@zzzcomputing.com

2016-01-28T20:01:31+00:00

8a1e619fb20df1be6ad2e0c563e451e17eb17628

the warning here to all safe_reraise() cases in Python 2.
- Revisiting :ticket:`2696`, first released in 1.0.10, which attempts to
work around Python 2's lack of exception context reporting by emitting
a warning for an exception that was interrupted by a second exception
when attempting to roll back the already-failed transaction; this
issue continues to occur for MySQL backends in conjunction with a
savepoint that gets unexpectedly lost, which then causes a
"no such savepoint" error when the rollback is attempted, obscuring
what the original condition was.

The approach has been generalized to the Core "safe
reraise" function which takes place across the ORM and Core in any
place that a transaction is being rolled back in response to an error
which occurred trying to commit, including the context managers
provided by :class:`.Session` and :class:`.Connection`, and taking
place for operations such as a failure on "RELEASE SAVEPOINT".
Previously, the fix was only in place for a specific path within
the ORM flush/commit process; it now takes place for all transational
context managers as well.
fixes #2696





the warning here to all safe_reraise() cases in Python 2.
- Revisiting :ticket:`2696`, first released in 1.0.10, which attempts to
work around Python 2's lack of exception context reporting by emitting
a warning for an exception that was interrupted by a second exception
when attempting to roll back the already-failed transaction; this
issue continues to occur for MySQL backends in conjunction with a
savepoint that gets unexpectedly lost, which then causes a
"no such savepoint" error when the rollback is attempted, obscuring
what the original condition was.

The approach has been generalized to the Core "safe
reraise" function which takes place across the ORM and Core in any
place that a transaction is being rolled back in response to an error
which occurred trying to commit, including the context managers
provided by :class:`.Session` and :class:`.Connection`, and taking
place for operations such as a failure on "RELEASE SAVEPOINT".
Previously, the fix was only in place for a specific path within
the ORM flush/commit process; it now takes place for all transational
context managers as well.
fixes #2696







fix %x string format to compatible with Python 3.5
2016-01-27T08:21:59+00:00

Ruilin Huang
cxghrl@gmail.com

2016-01-27T08:21:59+00:00

4b9f6f407ceedde247982501a6ae406242c80b4a












fix %x string format to compatible with Python 3.5
2016-01-27T08:10:06+00:00

xghrl
cxghrl@gmail.com

2016-01-27T08:10:06+00:00

324e532d6081d9b9ea90bf3945cecfc792264f8d












- rework ColumnCollection to no longer persist "all_col_set"; we don't
2016-01-26T21:41:26+00:00

Mike Bayer
mike_mp@zzzcomputing.com

2016-01-26T21:41:26+00:00

8163de4cc9e01460d3476b9fb3ed14a5b3e70bae

need this collection except in the extend/update uses where we
create it ad-hoc.  simplifies pickling.  Compatibility with 1.0
should be OK as ColumnColleciton uses __getstate__ in any case
and the __setstate__ contract hasn't changed.
- Fixed bug in :class:`.Table` metadata construct which appeared
around the 0.9 series where adding columns to a :class:`.Table`
that was unpickled would fail to correctly establish the
:class:`.Column` within the 'c' collection, leading to issues in
areas such as ORM configuration.   This could impact use cases such
as ``extend_existing`` and others.  fixes #3632





need this collection except in the extend/update uses where we
create it ad-hoc.  simplifies pickling.  Compatibility with 1.0
should be OK as ColumnColleciton uses __getstate__ in any case
and the __setstate__ contract hasn't changed.
- Fixed bug in :class:`.Table` metadata construct which appeared
around the 0.9 series where adding columns to a :class:`.Table`
that was unpickled would fail to correctly establish the
:class:`.Column` within the 'c' collection, leading to issues in
areas such as ORM configuration.   This could impact use cases such
as ``extend_existing`` and others.  fixes #3632







- The workaround for right-nested joins on SQLite, where they are rewritten
2016-01-26T21:09:23+00:00

Mike Bayer
mike_mp@zzzcomputing.com

2016-01-26T20:41:56+00:00

9d9fc93b7065d25a088e244961cf54606ad80b31

as subqueries in order to work around SQLite's lack of support for this
syntax, is lifted when SQLite version 3.7.16 or greater is detected.
fixes #3634
- The workaround for SQLite's unexpected delivery of column names as
``tablename.columnname`` for some kinds of queries is now disabled
when SQLite version 3.10.0 or greater is detected.
fixes #3633





as subqueries in order to work around SQLite's lack of support for this
syntax, is lifted when SQLite version 3.7.16 or greater is detected.
fixes #3634
- The workaround for SQLite's unexpected delivery of column names as
``tablename.columnname`` for some kinds of queries is now disabled
when SQLite version 3.10.0 or greater is detected.
fixes #3633