<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/python-packages/sqlalchemy.git/lib/sqlalchemy/dialects/mysql/base.py, branch pr/23</title>
<subtitle>github.com: zzzeek/sqlalchemy.git
</subtitle>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/'/>
<entry>
<title>move FAQ to the docs, [ticket:2133]</title>
<updated>2013-08-21T22:48:34+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-08-21T22:48:34+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=4268ea06b3efe116361157fa2ad155b2347d2bba'/>
<id>4268ea06b3efe116361157fa2ad155b2347d2bba</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>- A large refactoring of the ``sqlalchemy.sql`` package has reorganized</title>
<updated>2013-08-12T21:50:37+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-08-12T21:50:37+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=f6198d9abf453182f4b111e0579a7a4ef1614e79'/>
<id>f6198d9abf453182f4b111e0579a7a4ef1614e79</id>
<content type='text'>
the import structure of many core modules.
``sqlalchemy.schema`` and ``sqlalchemy.types``
remain in the top-level package, but are now just lists of names
that pull from within ``sqlalchemy.sql``.  Their implementations
are now broken out among ``sqlalchemy.sql.type_api``, ``sqlalchemy.sql.sqltypes``,
``sqlalchemy.sql.schema`` and ``sqlalchemy.sql.ddl``, the last of which was
moved from ``sqlalchemy.engine``.  ``sqlalchemy.sql.expression`` is also
a namespace now which pulls implementations mostly from ``sqlalchemy.sql.elements``,
``sqlalchemy.sql.selectable``, and ``sqlalchemy.sql.dml``.
Most of the "factory" functions
used to create SQL expression objects have been moved to classmethods
or constructors, which are exposed in ``sqlalchemy.sql.expression``
using a programmatic system.  Care has been taken such that all the
original import namespaces remain intact and there should be no impact
on any existing applications.   The rationale here was to break out these
very large modules into smaller ones, provide more manageable lists
of function names, to greatly reduce "import cycles" and clarify the
up-front importing of names, and to remove the need for redundant
functions and documentation throughout the expression package.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
the import structure of many core modules.
``sqlalchemy.schema`` and ``sqlalchemy.types``
remain in the top-level package, but are now just lists of names
that pull from within ``sqlalchemy.sql``.  Their implementations
are now broken out among ``sqlalchemy.sql.type_api``, ``sqlalchemy.sql.sqltypes``,
``sqlalchemy.sql.schema`` and ``sqlalchemy.sql.ddl``, the last of which was
moved from ``sqlalchemy.engine``.  ``sqlalchemy.sql.expression`` is also
a namespace now which pulls implementations mostly from ``sqlalchemy.sql.elements``,
``sqlalchemy.sql.selectable``, and ``sqlalchemy.sql.dml``.
Most of the "factory" functions
used to create SQL expression objects have been moved to classmethods
or constructors, which are exposed in ``sqlalchemy.sql.expression``
using a programmatic system.  Care has been taken such that all the
original import namespaces remain intact and there should be no impact
on any existing applications.   The rationale here was to break out these
very large modules into smaller ones, provide more manageable lists
of function names, to greatly reduce "import cycles" and clarify the
up-front importing of names, and to remove the need for redundant
functions and documentation throughout the expression package.
</pre>
</div>
</content>
</entry>
<entry>
<title>Updates to MySQL reserved words for versions 5.5, 5.6, courtesy</title>
<updated>2013-08-01T01:05:33+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-08-01T01:05:33+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=25839c064d995b3664f0cef01768961ac5e4807f'/>
<id>25839c064d995b3664f0cef01768961ac5e4807f</id>
<content type='text'>
Hanno Schlichting.  Also in 0.8.3, 0.7.11.
[ticket:2791]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Hanno Schlichting.  Also in 0.8.3, 0.7.11.
[ticket:2791]
</pre>
</div>
</content>
</entry>
<entry>
<title>this comment is ancient</title>
<updated>2013-06-10T00:36:37+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-06-10T00:36:37+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=1652491cc6ef44c803e58c0d842818ab7310f498'/>
<id>1652491cc6ef44c803e58c0d842818ab7310f498</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Add basic support of unique constraints reflection</title>
<updated>2013-06-09T20:49:55+00:00</updated>
<author>
<name>Roman Podolyaka</name>
<email>roman.podolyaka@gmail.com</email>
</author>
<published>2013-06-09T16:07:00+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=c69fe4acf8929856735e5d90adb7f6b6d5ebcd46'/>
<id>c69fe4acf8929856735e5d90adb7f6b6d5ebcd46</id>
<content type='text'>
Inspection API already supports reflection of table
indexes information and those also include unique
constraints (at least for PostgreSQL and MySQL).
But it could be actually useful to distinguish between
indexes and plain unique constraints (though both are
implemented in the same way internally in RDBMS).

This change adds a new method to Inspection API - get_unique_constraints()
and implements it for SQLite, PostgreSQL and MySQL dialects.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Inspection API already supports reflection of table
indexes information and those also include unique
constraints (at least for PostgreSQL and MySQL).
But it could be actually useful to distinguish between
indexes and plain unique constraints (though both are
implemented in the same way internally in RDBMS).

This change adds a new method to Inspection API - get_unique_constraints()
and implements it for SQLite, PostgreSQL and MySQL dialects.
</pre>
</div>
</content>
</entry>
<entry>
<title>- changelog for [ticket:2704]</title>
<updated>2013-06-08T18:47:04+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-06-08T18:47:04+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=a80bb5393484ed2579266c8780ddea1507515e37'/>
<id>a80bb5393484ed2579266c8780ddea1507515e37</id>
<content type='text'>
- use an isinstance() check, concerned a TypeError might be indiscriminate
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
- use an isinstance() check, concerned a TypeError might be indiscriminate
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix using of 'mysql_length' for composite indexes</title>
<updated>2013-06-08T17:56:28+00:00</updated>
<author>
<name>Roman Podolyaka</name>
<email>roman.podolyaka@gmail.com</email>
</author>
<published>2013-06-08T17:38:02+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=4cc9d482ae8edc2ac60aaf4102bab84148691fed'/>
<id>4cc9d482ae8edc2ac60aaf4102bab84148691fed</id>
<content type='text'>
Currently, one can specify the prefix length for an index
column using 'mysql_length' keyword argument when creating
an Index instance. But in case of composite indexes the
prefix length value is applied only to the last column.

Extend the existing API in way so that 'mysql_length' argument
value can be either:
    - an integer specifying the same prefix length value
      for each column of an index
    - a (column_name --&gt; integer value) mapping specifying
      the prefix length value for each column of an index
      separately

Fixes issue #2704.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, one can specify the prefix length for an index
column using 'mysql_length' keyword argument when creating
an Index instance. But in case of composite indexes the
prefix length value is applied only to the last column.

Extend the existing API in way so that 'mysql_length' argument
value can be either:
    - an integer specifying the same prefix length value
      for each column of an index
    - a (column_name --&gt; integer value) mapping specifying
      the prefix length value for each column of an index
      separately

Fixes issue #2704.
</pre>
</div>
</content>
</entry>
<entry>
<title>The ``deferrable`` keyword argument on :class:`.ForeignKey` and</title>
<updated>2013-06-03T22:33:20+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-06-03T22:33:20+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=ada19275299f0105f4aaed5bbe0d373ea33feea6'/>
<id>ada19275299f0105f4aaed5bbe0d373ea33feea6</id>
<content type='text'>
:class:`.ForeignKeyConstraint` will not render the ``DEFERRABLE`` keyword
on the MySQL dialect.  For a long time we left this in place because
a non-deferrable foreign key would act very differently than a deferrable
one, but some environments just disable FKs on MySQL, so we'll be less
opinionated here. [ticket:2721]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
:class:`.ForeignKeyConstraint` will not render the ``DEFERRABLE`` keyword
on the MySQL dialect.  For a long time we left this in place because
a non-deferrable foreign key would act very differently than a deferrable
one, but some environments just disable FKs on MySQL, so we'll be less
opinionated here. [ticket:2721]
</pre>
</div>
</content>
</entry>
<entry>
<title>mysql tests</title>
<updated>2013-05-26T20:32:55+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-05-26T20:32:55+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=f939abe83034840b6c304df5ea4dfda5e9dc4633'/>
<id>f939abe83034840b6c304df5ea4dfda5e9dc4633</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>merge default</title>
<updated>2013-04-29T23:28:29+00:00</updated>
<author>
<name>Mike Bayer</name>
<email>mike_mp@zzzcomputing.com</email>
</author>
<published>2013-04-29T23:28:29+00:00</published>
<link rel='alternate' type='text/html' href='http://91.123.203.49/cgit/delta/python-packages/sqlalchemy.git/commit/?id=093c322719c0acb6b37836d5e7eacbaae072e478'/>
<id>093c322719c0acb6b37836d5e7eacbaae072e478</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
</feed>
