delta/python-packages/sqlalchemy.git/lib/sqlalchemy/engine, branch pr/65 github.com: zzzeek/sqlalchemy.git - Fixed 0.9 regression where the new sortable support for :class:`.RowProxy` 2014-01-29T04:43:14+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-29T04:43:14+00:00 d4c908ded1e9a7923312f3b335835e7e40b6690e would lead to ``TypeError`` when compared to non-tuple types as it attempted to apply tuple() to the "other" object unconditionally. The full range of Python comparison operators have now been implemented on :class:`.RowProxy`, using an approach that guarantees a comparison system that is equivalent to that of a tuple, and the "other" object is only coerced if it's an instance of RowProxy. [ticket:2924] 
would lead to ``TypeError`` when compared to non-tuple types as it attempted
to apply tuple() to the "other" object unconditionally.  The
full range of Python comparison operators have now been implemented on
:class:`.RowProxy`, using an approach that guarantees a comparison
system that is equivalent to that of a tuple, and the "other" object
is only coerced if it's an instance of RowProxy. [ticket:2924]
- doc updates, include links to create_engine from tutorials, cleanup 2014-01-24T00:38:46+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-24T00:38:46+00:00 fd7b951f9dc41bad6dfe6c5042555aad5d23ef06 and modernize the engines chapter a bit 
and modernize the engines chapter a bit
- Fixed the multiple-table "UPDATE..FROM" construct, only usable on 2014-01-21T02:17:42+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-21T02:01:35+00:00 b9318c98637bbd5c19267728fcfe941668345325 MySQL, to correctly render the SET clause among multiple columns with the same name across tables. This also changes the name used for the bound parameter in the SET clause to "<tablename>_<colname>" for the non-primary table only; as this parameter is typically specified using the :class:`.Column` object directly this should not have an impact on applications. The fix takes effect for both :meth:`.Table.update` as well as :meth:`.Query.update` in the ORM. [ticket:2912] 
MySQL, to correctly render the SET clause among multiple columns
with the same name across tables.  This also changes the name used for
the bound parameter in the SET clause to "<tablename>_<colname>" for
the non-primary table only; as this parameter is typically specified
using the :class:`.Column` object directly this should not have an
impact on applications.   The fix takes effect for both
:meth:`.Table.update` as well as :meth:`.Query.update` in the ORM.
[ticket:2912]
- further refine this so that the ordering of columns is maintained as 2014-01-20T23:14:02+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-20T23:14:02+00:00 417aeaf1453c67130fb8f1a2bb21c38e6795ce25 sent to the primary key constraint; existing tests in the PG dialect confirm this. 
sent to the primary key constraint; existing tests in the PG dialect
confirm this.
- simplify the mechanics of PrimaryKeyConstraint with regards to reflection; 2014-01-20T23:06:18+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-20T22:55:01+00:00 49f1807f8f2acea5494fa77d217dce813a933147 reflection now updates the PKC in place. - support the use case of the empty PrimaryKeyConstraint in order to specify constraint options; the columns marked as primary_key=True will now be gathered into the columns collection, rather than being ignored. [ticket:2910] - add validation such that column specification should only take place in the PrimaryKeyConstraint directly, or by using primary_key=True flags; if both are present, they have to match exactly, otherwise the condition is assumed to be ambiguous, and a warning is emitted; the old behavior of using the PKC columns only is maintained. 
reflection now updates the PKC in place.
- support the use case of the empty PrimaryKeyConstraint in order to specify
constraint options; the columns marked as primary_key=True will now be gathered
into the columns collection, rather than being ignored. [ticket:2910]
- add validation such that column specification should only take place
in the PrimaryKeyConstraint directly, or by using primary_key=True flags;
if both are present, they have to match exactly, otherwise the condition is
assumed to be ambiguous, and a warning is emitted; the old behavior of
using the PKC columns only is maintained.
- repair signature for base get_unique_constraints() method 2014-01-20T21:09:40+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-20T21:09:40+00:00 44cba66cb2eb4411b43c228c4f1191c764607855 - test_autoincrement_col still needs reflection overall 
- test_autoincrement_col still needs reflection overall
- some test fixes 2014-01-19T05:34:37+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-19T05:34:37+00:00 8e1a4fdced253a58af309c93c24a8a492b646bb7 - clean up some shenanigans in reflection 
- clean up some shenanigans in reflection
- implement kwarg validation and type system for dialect-specific 2014-01-19T00:26:56+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-19T00:26:56+00:00 1af8e2491dcbed723d2cdafd44fd37f1a6908e91 arguments; [ticket:2866] - add dialect specific kwarg functionality to ForeignKeyConstraint, ForeignKey 
arguments; [ticket:2866]
- add dialect specific kwarg functionality to ForeignKeyConstraint, ForeignKey
- _cursor_execute() will close the cursor on error; oracle doesn't allow double close 2014-01-14T02:20:54+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-14T02:20:54+00:00 52b25c5319b982486348069e2d9edd5259be03d3 - ensure no iterator changed size issues in testing.engines 
- ensure no iterator changed size issues in testing.engines
- The MySQL CAST compilation now takes into account aspects of a string 2014-01-13T19:05:05+00:00 Mike Bayer mike_mp@zzzcomputing.com 2014-01-13T19:05:05+00:00 1536bc4664a248faf81c62326fe1be3dbe18b8cd type such as "charset" and "collation". While MySQL wants all character- based CAST calls to use the CHAR type, we now create a real CHAR object at CAST time and copy over all the parameters it has, so that an expression like ``cast(x, mysql.TEXT(charset='utf8'))`` will render ``CAST(t.col AS CHAR CHARACTER SET utf8)``. - Added new "unicode returns" detection to the MySQL dialect and to the default dialect system overall, such that any dialect can add extra "tests" to the on-first-connect "does this DBAPI return unicode directly?" detection. In this case, we are adding a check specifically against the "utf8" encoding with an explicit "utf8_bin" collation type (after checking that this collation is available) to test for some buggy unicode behavior observed with MySQLdb version 1.2.3. While MySQLdb has resolved this issue as of 1.2.4, the check here should guard against regressions. The change also allows the "unicode" checks to log in the engine logs, which was not previously the case. [ticket:2906] 
type such as "charset" and "collation".  While MySQL wants all character-
based CAST calls to use the CHAR type, we now create a real CHAR
object at CAST time and copy over all the parameters it has, so that
an expression like ``cast(x, mysql.TEXT(charset='utf8'))`` will
render ``CAST(t.col AS CHAR CHARACTER SET utf8)``.

- Added new "unicode returns" detection to the MySQL dialect and
to the default dialect system overall, such that any dialect
can add extra "tests" to the on-first-connect "does this DBAPI
return unicode directly?" detection. In this case, we are
adding a check specifically against the "utf8" encoding with
an explicit "utf8_bin" collation type (after checking that
this collation is available) to test for some buggy unicode
behavior observed with MySQLdb version 1.2.3.  While MySQLdb
has resolved this issue as of 1.2.4, the check here should
guard against regressions.  The change also allows the "unicode"
checks to log in the engine logs, which was not previously
the case. [ticket:2906]