| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
- restore mysqldb fully within dialects/mysql/, it's no longer a connector.
fixes #2984
|
| |
|
|
|
|
|
|
|
|
| |
pymysql) from working in Py3K, where a check for "connection
charset" would fail due to Py3K's more strict value comparison
rules. The call in question wasn't taking the database
version into account in any case as the server version was
still None at that point, so the method overall has been
simplified to rely upon connection.character_set_name().
[ticket:2933]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
except for the changelog part
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
dialect. [ticket:2554]
|
| |
|
|
|
|
| |
- visit_mods all seemed to not propagate **kw down to process().
this is [ticket:2548] which may be backported to 0.7 pending
a test case to illustrate wrong behavior.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on windows, after aggressive exclusion of a wide variety
of tests. Not clear to what degree the failures are related to
version 5.5 vs. the usage of windows, in particular the ON UPDATE CASCADE
immediately crashes the server. The features being tested here are all
edge cases not likely to be used in typical MySQL environments.
- Removed the "adjust casing" step that would
fail when reflecting a table on MySQL
on windows with a mixed case name. After some
experimenting with a windows MySQL server, it's
been determined that this step wasn't really
helping the situation much; MySQL does not return
FK names with proper casing on non-windows
platforms either, and removing the step at
least allows the reflection to act more like
it does on other OSes. A warning here
has been considered but its difficult to
determine under what conditions such a warning
can be raised, so punted on that for now -
added some docs instead. [ticket:2181]
- supports_sane_rowcount will be set to False
if using MySQLdb and the DBAPI doesn't provide
the constants.CLIENT module.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SchemaEventTarget, which supplies dispatch
- the dispatch now provides before_parent_attach(),
after_parent_attach(), events which generally bound the _set_parent()
event. [ticket:2037]
- the _on_table_attach mechanism now usually uses the
event dispatch
- fixed class-level event dispatch to propagate to all subclasses, not just
immediate subclasses
- fixed class-level event unpickling to handle more involved
inheritance hierarchies, needed by the new schema event dispatch.
- ForeignKeyConstraint doesn't re-call the column attach event
on ForeignKey objects that are already associated with the correct
Column
- we still need that ImportError on mysqldb CLIENT FLAGS to support
mock DBAPIs
|
| | |
|
| |
|
|
| |
of MySQL-python. [ticket:1991]
|
|
|
- move mysqldb to a connector, can be shared among mysql/drizzle
|
