| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Found using: https://github.com/intgr/topy
|
| |
|
|
|
|
|
| |
to use the ``database_principal_id()`` function in conjunction with
the ``sys.database_principals`` view so that we can determine
the default schema independently of the type of login in progress
(e.g., SQL Server, Windows, etc). fixes #3025
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
it for DELETE would fail to target the correct row for DELETE.
Then to compound matters, basic "number of rows matched" checks were
not being performed. Both issues are fixed, however note that the
"rows matched" check requires so-called "sane multi-row count"
functionality; the DBAPI's executemany() method must count up the
rows matched by individual statements and SQLAlchemy's dialect must
mark this feature as supported, currently applies to some mysql dialects,
psycopg2, sqlite only. fixes #3006
- Enabled "sane multi-row count" checking for the psycopg2 DBAPI, as
this seems to be supported as of psycopg2 2.0.9.
|
| |
|
|
|
|
|
|
|
|
|
| |
"supports unicode statements" flag is now False, so that SQLAlchemy
will encode the *SQL string* (note: *not* the parameters)
to bytes before sending to the database. This seems to allow
all unicode-related tests to pass for mysql-connector, including those
that use non-ascii table/column names, as well as some tests for the
TEXT type using unicode under cursor.executemany().
- other mysql-connector fixes; latest version seems to do better on
function call counts
|
| |
|
|
|
|
|
|
|
| |
enhancements where index reflection on Postgresql versions specific
to only the 8.1, 8.2 series again
broke, surrounding the ever problematic int2vector type. While
int2vector supports array operations as of 8.1, apparently it only
supports CAST to a varchar as of 8.3.
fix #3000
|
| |
|
|
|
|
|
|
|
|
|
|
| |
:class:`.DateTime`. As Oracle has no "datetime" type per se,
it instead has only ``DATE``, it is appropriate here that the
``DATE`` type as present in the Oracle dialect be an instance of
:class:`.DateTime`. This issue doesn't change anything as far as
the behavior of the type, as data conversion is handled by the
DBAPI in any case, however the improved subclass layout will help
the use cases of inspecting types for cross-database compatibility.
Also removed uppercase ``DATETIME`` from the Oracle dialect as this
type isn't functional in that context. fixes #2987
|
| | |
|
| |\
| |
| | |
Update URL for pymssql
|
| | |
| |
| |
| | |
@zzzeek.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
- various improvemnts to oracle docs, rewrite section on unicode, more linking,
enhance section on resolve_synonyms
|
| |\ \ |
|
| | |/
| |
| |
| | |
This feature is now turned off by default.
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
"could not send data to server", which complements the existing
"could not receive data from server" and has been observed by users,
fixes #2936
|
| |
|
|
| |
for output consistency within the tests as well as in practice
|
| |
|
|
|
|
|
| |
fractional seconds support; also added fractional seconds support
to :class:`.mysql.TIMESTAMP`. DBAPI support is limited, though
fractional seconds are known to be supported by MySQL Connector/Python.
Patch courtesy Geert JM Vanderkelen. #2941
|
| |\
| |
| |
| | |
into t
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(pre 8.1) versions of Postgresql, and potentially other PG engines
such as Redshift (assuming Redshift reports the version as < 8.1).
The query for "indexes" as well as "primary keys" relies upon inspecting
a so-called "int2vector" datatype, which refuses to coerce to an array
prior to 8.1 causing failures regarding the "ANY()" operator used
in the query. Extensive googling has located the very hacky, but
recommended-by-PG-core-developer query to use when PG version < 8.1
is in use, so index and primary key constraint reflection now work
on these versions.
|
| | | |
|
| | |
| |
| |
| | |
both _resolve_type_affinity() directly as well as round trip tests fully.
|
| | |
| |
| |
| |
| |
| | |
types; such as if it encounters a string like ``INTEGER(5)``, the
:class:`.INTEGER` type will be instantiated without the "5" being included,
based on detecting a ``TypeError`` on the first attempt.
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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!).
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
python_type for ARRAY (PGArray)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
hstore extension. #2959
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
- clarify section on "foreign key reflection" and group this in a
section that refers to foreign keys.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
query for "show standard_conforming_strings"; as this variable was
added as of PG 8.2, we skip the query for PG versions older than
that as well as for backends like Redshift. #2946
|
| | |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
reflection query were updated to take into account primary key constraints
that were renamed; the newer query fails on very old versions of
Postgresql such as version 7, so the old query is restored in those cases
when server_version_info < (8, 0) is detected. #2291
|
| | | |
| | |
| | |
| | | |
Closes #2934
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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]
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
to support dialect-level reflection options for all :class:`.Table`
objects reflected.
- Added a new dialect-level argument ``postgresql_ignore_search_path``;
this argument is accepted by both the :class:`.Table` constructor
as well as by the :meth:`.MetaData.reflect` method. When in use
against Postgresql, a foreign-key referenced table which specifies
a remote schema name will retain that schema name even if the name
is present in the ``search_path``; the default behavior since 0.7.3
has been that schemas present in ``search_path`` would not be copied
to reflected :class:`.ForeignKey` objects. The documentation has been
updated to describe in detail the behavior of the ``pg_get_constraintdef()``
function and how the ``postgresql_ignore_search_path`` feature essentially
determines if we will honor the schema qualification reported by
this function or not. [ticket:2922]
|
| |/
|
|
|
|
|
|
|
|
| |
such as "literal binds" into a CAST expression.
- Fixed bug whereby binary type would fail in some cases
if used with a "test" dialect, such as a DefaultDialect or other
dialect with no DBAPI.
- Fixed bug where "literal binds" wouldn't work with a bound parameter
that's a binary type. A similar, but different, issue is fixed
in 0.8.
|
| |
|
|
|
|
|
|
|
|
|
| |
where a more specific type is adapted to a more generic one - this
use case is needed by some third party tools such as ``sqlacodegen``.
The specific cases that needed repair within this test suite were that
of :class:`.mysql.ENUM` being downcast into a :class:`.types.Enum`,
and that of SQLite date types being cast into generic date types.
The ``adapt()`` method needed to become more specific here to counteract
the removal of a "catch all" ``**kwargs`` collection on the base
:class:`.TypeEngine` class that was removed in 0.9. [ticket:2917]
|
| |
|
|
| |
- clean up some shenanigans in reflection
|
| |
|
|
|
| |
arguments; [ticket:2866]
- add dialect specific kwarg functionality to ForeignKeyConstraint, ForeignKey
|
| |
|
|
| |
- be specific about version 0.9.2
|
| |\
| |
| |
| | |
into m
|
| | | |
|
| | | |
|
| | | |
|
