| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Change-Id: Ida0d01ae9bcc0573b86e24fddea620a38c962822
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new class of "rowcount support" for dialects that is specific to
when "RETURNING", which on SQL Server looks like "OUTPUT inserted", is in
use, as the PyODBC backend isn't able to give us rowcount on an UPDATE or
DELETE statement when OUTPUT is in effect. This primarily affects the ORM
when a flush is updating a row that contains server-calcluated values,
raising an error if the backend does not return the expected row count.
PyODBC now states that it supports rowcount except if OUTPUT.inserted is
present, which is taken into account by the ORM during a flush as to
whether it will look for a rowcount.
ORM tests are implicit in existing tests run against PyODBC
Fixes: #4062
Change-Id: Iff17cbe4c7a5742971ed85a4d58660c18cc569c2
|
| |
|
|
|
|
|
| |
In prep for CI coverage for SQL Server, allow AUTOCOMMIT
isolation level to work
Change-Id: I850b977e75f53385986f2c181be4e4412dd3b3f4
|
| |
|
|
|
|
|
|
|
|
|
| |
Corrects some warnings and adds tox config. Adds DeprecationWarning
to the error category. Large sweep for string literals w/ backslashes
as this is common in docstrings
Co-authored-by: Andrii Soldatenko
Fixes: #3886
Change-Id: Ia7c838dfbbe70b262622ed0803d581edc736e085
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/337
|
| |
|
|
| |
Change-Id: I4e8c2aa8fe817bb2af8707410fa0201f938781de
|
| |
|
|
|
|
|
|
|
|
| |
Fixed bug in pyodbc dialect (as well as in the mostly non-working
adodbapi dialect) whereby a semicolon present in the password
or username fields could be interpreted as a separator for another
token; the values are now quoted when semicolons are present.
Change-Id: I5f99fd8db53ebf8e805e7d9d60bc09b8f1af603f
Fixes: #3762
|
| |
|
|
|
|
|
|
|
| |
Updated the server version info scheme for pyodbc to use SQL Server
SERVERPROPERTY(), rather than relying upon pyodbc.SQL_DBMS_VER, which
continues to be unreliable particularly with FreeTDS.
Change-Id: I4ff49ae13c8ff51bd764980131d41c18d73d87ce
Fixes: #3814
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
pyodbc will no longer specify a default "driver name", and a warning
is emitted if this is missing. The optimal driver name for SQL Server
changes frequently and is per-platform, so hostname based connections
need to specify this. DSN-based connections are preferred.
fixes #3182
|
| |
|
|
|
|
|
|
|
| |
statements which operate when an explicit INSERT is being
interjected into an IDENTITY column, to support non-ascii table
identifiers on drivers such as pyodbc + unix + py2k that don't
support unicode statements.
ref #3091 as this fix is also in that issue's patch, but is
a different issue.
|
| | |
|
| |
|
|
| |
to get all flake8 passing
|
| |
|
|
|
| |
- 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
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
not happening too well (I need to stick with linux + freetds 0.91, I know)
|
| | |
|
| |
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
| | |
|
| | |
|
| |
|
|
| |
dialect. [ticket:2554]
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
- enhancements to test suite including ability to set up a testing engine
for a whole test class, fixes to how noseplugin sets up/tears
down per-class context
|
| |
|
|
|
|
| |
- 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.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- [bug] Removed warning when Index is created
with no columns; while this might not be what
the user intended, it is a valid use case
as an Index could be a placeholder for just an
index of a certain name.
- mssql
- [feature] Added interim create_engine flag
supports_unicode_binds to PyODBC dialect,
to force whether or not the dialect
passes Python unicode literals to PyODBC
or not.
|
| | |
|
| |
|
|
|
|
|
|
| |
pyodbc accurately as far as observed
pyodbc strings, including such gems
as "py3-3.0.1-beta4" [ticket:2318]
- [bug] use new pyodbc version detection for
_need_decimal_fix option, [ticket:2318]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Pyodbc. This includes that string binds are sent as
Python unicode objects when FreeTDS 0.91 is detected,
and a CAST(? AS NVARCHAR) is used when we detect
for a table. However, I'd continue
to characterize Pyodbc + FreeTDS 0.91 behavior as
pretty crappy, there are still many queries such
as used in reflection which cause a core dump on
Linux, and it is not really usable at all
on OSX, MemoryErrors abound and just plain broken
unicode support. [ticket:2273]
|
| |
|
|
|
|
|
|
|
| |
values are passed as bytes and not unicode
if the "Easysoft" unix drivers are detected.
This is the same behavior as occurs with
FreeTDS. Easysoft appears to segfault
if Python unicodes are passed under
certain circumstances.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
but we'd like to. Most DBAPIs don't give us anything we can do with it.
Some research was done on psycopg2 and it still seems like they give us
no adequate method (tried connection.closed, cursor.closed, connection.status).
mxodbc claims their .closed attribute will work (but I am skeptical).
- remove beahvior in pool that auto-invalidated a connection when
the cursor failed to create. That's not the pool's job. we need the conn
for the error logic. Can't get any tests to fail, curious why that
behavior was there, guess we'll find out (or not).
- add support for psycopg2 version detection. even though we have
no use for it yet...
- adjust one of the reconnect tests to work with oracle's
horrendously slow connect speed
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
| |
a consistent tag
- AUTHORS file
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- add --with-cdecimal flag to tests, monkeypatches cdecimal in
- fix mssql/pyodbc.py to not use private '_int' accessor in decimal conversion
routines
- pyodbc version 2.1.8 is needed for cdecimal in any case as
previous versions also called '_int', 2.1.8 adds the same string
logic as our own dialect, so that logic is skipped for modern
pyodbc version
- make the imports for "Decimal" consistent across the whole lib. not sure
yet how we should be importing "Decimal" or what the best way forward
is that would allow a clean user-invoked swap of cdecimal; for now,
added docs suggesting a global monkeypatch - the two decimal libs
are not compatible with each other so any chance of mixing produces
serious issues. adding adapters to DBAPIs tedious and adds in-python
overhead. suggestions welcome on how we should be doing
Decimal/cdecimal.
|
| | |
|