an issue with utf8, and this should be part of the testing URL in any case. if we observe failures on some drivers/etc. this can become a "requires"
concurrent ability to return connections from the pool means that the "first_connect" event is now no longer synchronized either, thus leading to dialect mis-configurations under even minimal concurrency situations.
SQLite allows column types that aren't technically understood in sqlite by using 'data affinity', which is an algorithm for converting column types in to some sort of useful type that can be stored and retrieved from the db. Unfortunatly, this breaks reflection since we (previously) expected a sqlite db to reflect column types that we permit in the `ischema_names` for that dialect. This patch changes the logic for 'unknown' column types during reflection to instead run through SQLite's data affinity algorithm, and assigns appropriate types from that. It also expands the matching for column type to include column types with spaces (strongly discouraged but allowed by sqlite) and also completely empty column types (in which case the NullType is assigned, which sqlite will treat as a Blob - or rather, Blob is treated as NullType). These changes mean that SQLite will never raise an error for an unknown type during reflection - there will always be some 'useful' type returned, which follows the spirit of SQLite (accomodation before sanity!).
applied to :class:`.Constraint` and :class:`.Index` objects. Based
on a recipe in the wiki, the new feature uses schema-events to set up
names as various schema objects are associated with each other. The
events then expose a configuration system through a new argument
:paramref:`.MetaData.naming_convention`. This system allows production
of both simple and custom naming schemes for constraints and indexes
on a per-:class:`.MetaData` basis. [ticket:2923]
commit 7e65e52c086652de3dd3303c723f98f09af54db8
Author: Mike Bayer <mike_mp@zzzcomputing.com>
Date: Sat Feb 1 15:09:04 2014 -0500
- first pass at new naming approach
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.
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]