| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
as up-to-date recommendations as possible
|
|\
| |
| |
| |
| | |
Conflicts:
lib/sqlalchemy/dialects/mysql/mysqldb.py
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
| |
format
- add an extra doc to MySQLdb
- changelog
|
|
|
|
|
| |
check for 'utf8_bin' collation, as this fails on MySQL server < 5.0.
fixes #3274
|
|
|
|
|
|
|
|
|
| |
and Pymysql under Python 2. This refers to the SQL statements
themselves, not the parameters, and affects issues such as table
and column names using non-ASCII characters. These drivers both
appear to support Python 2 Unicode objects without issue in modern
versions.
fixes #3121
|
|
|
|
| |
sqlalchemy/orm, sqlalchemy/event, sqlalchemy/testing
|
|
|
|
| |
to get all flake8 passing
|
|
|
|
|
| |
- restore mysqldb fully within dialects/mysql/, it's no longer a connector.
fixes #2984
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
- build a new Sphinx extension that allows dialect info
to be entered as directives which is then rendered consistently
throughout all dialect/dbapi sections
- break out the "empty_strings" requirement for oracle test
|
|
|
|
|
|
| |
- begin consolidating docs for dialects to be more self contained
- add a separate section for "external" dialects
- not sure how we're going to go with this yet.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
of MySQL-python. [ticket:1991]
|
|
|
|
| |
- move mysqldb to a connector, can be shared among mysql/drizzle
|
| |
|
|
|
|
|
| |
a consistent tag
- AUTHORS file
|
|
|
|
|
| |
for all four MySQL dialects. has_table() passes in the "orig"
from the SQLAlchemy exception. continuing of [ticket:1848]
|
|
|
|
|
|
|
|
|
| |
correctly with the "mysqldb" dialect. Previously,
the reconnect logic would fail for OperationalError
conditions, however since MySQLdb has its
own reconnect feature, there was no symptom
here unless one watched the logs.
[ticket:1848]
|
| |
|
|
|
|
|
|
|
| |
mysql dialects.
- added an explicit test for [ticket:1216]
- some questions remain about MSSQL - would like to simplify/remove bind handling for numerics
|
|
|
|
| |
[ticket:1738]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
reimplementing the highest impact functions.
The actual speedups will depend heavily on your DBAPI and
the mix of datatypes used in your tables, and can vary from
a 50% improvement to more than 200%. It also provides a modest
(~20%) indirect improvement to ORM speed for large queries.
Note that it is *not* built/installed by default.
See README for installation instructions.
- The most common result processors conversion function were
moved to the new "processors" module. Dialect authors are
encouraged to use those functions whenever they correspond
to their needs instead of implementing custom ones.
|
|
|
|
| |
- fixed result processor for Numeric(asdecimal=False) on MSSQL.
|
|
|
|
|
|
|
|
|
|
| |
types to more intelligently determine float() vs. Decimal(),
[ticket:1567]
- since result processing is a hot issue of late, the DBAPI type
returned from cursor.description is certainly useful in cases like
these to determine an efficient result processor. There's likely
other result processors that can make use of it. But, backwards
incompat change to result_processor(). Happy major version number..
|
|
|
|
|
| |
- support exceptions raised in dialect initialize phase
- provide default dialect create_connect_args() method
|
|
|
|
|
|
|
| |
thus allowing easy subclassing
- move % sign logic for MySQLIdentifierPreparer into MySQLdb dialect
- paramterize the escape/unescape quote char in IdentifierPreparer
- cut out MySQLTableDefinitionParser cruft
|
|
|