summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/dialects
Commit message (Collapse)AuthorAgeFilesLines
...
* Remove object in class definitionFederico Caselli2021-11-2210-14/+14
| | | | | References: #4600 Change-Id: I2a62ddfe00bc562720f0eae700a497495d7a987a
* Merge "fully support isolation_level parameter in base dialect" into mainmike bayer2021-11-1812-187/+53
|\
| * fully support isolation_level parameter in base dialectMike Bayer2021-11-1812-187/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generalized the :paramref:`_sa.create_engine.isolation_level` parameter to the base dialect so that it is no longer dependent on individual dialects to be present. This parameter sets up the "isolation level" setting to occur for all new database connections as soon as they are created by the connection pool, where the value then stays set without being reset on every checkin. The :paramref:`_sa.create_engine.isolation_level` parameter is essentially equivalent in functionality to using the :paramref:`_engine.Engine.execution_options.isolation_level` parameter via :meth:`_engine.Engine.execution_options` for an engine-wide setting. The difference is in that the former setting assigns the isolation level just once when a connection is created, the latter sets and resets the given level on each connection checkout. Fixes: #6342 Change-Id: Id81d6b1c1a94371d901ada728a610696e09e9741
* | Merge "Add new sections regarding schemas and reflection" into mainmike bayer2021-11-181-25/+25
|\ \
| * | Add new sections regarding schemas and reflectionjonathan vanasco2021-11-171-25/+25
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * add a new section to reflection.rst `Schemas and Reflection`. * this contains some text from the ticket * migrate some text from `Specifying the Schema Name` to new section * migrate some text from PostgreSQL dialect to new section * target text is made more generic * cross-reference the postgres and new sections to one another, to avoid duplication of docs * update some docs 'meta' to 'metadata_obj' Fixes: #4387 Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: I2b08672753fb2575d30ada07ead77587468fdade
* | Merge "Deprecate create_engine.implicit_returning" into mainmike bayer2021-11-181-3/+7
|\ \ | |/ |/|
| * Deprecate create_engine.implicit_returningjonathan vanasco2021-11-091-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The :paramref:`_sa.create_engine.implicit_returning` parameter is deprecated on the :func:`_sa.create_engine` function only; the parameter remains available on the :class:`_schema.Table` object. This parameter was originally intended to enable the "implicit returning" feature of SQLAlchemy when it was first developed and was not enabled by default. Under modern use, there's no reason this parameter should be disabled, and it has been observed to cause confusion as it degrades performance and makes it more difficult for the ORM to retrieve recently inserted server defaults. The parameter remains available on :class:`_schema.Table` to specifically suit database-level edge cases which make RETURNING infeasible, the sole example currently being SQL Server's limitation that INSERT RETURNING may not be used on a table that has INSERT triggers on it. Also removed from the Oracle dialect some logic that would upgrade an Oracle 8/8i server version to use implicit returning if the parameter were explictly passed; these versions of Oracle still support RETURNING so the feature is now enabled for all Oracle versions. Fixes: #6962 Change-Id: Ib338e300cd7c8026c3083043f645084a8211aed8
* | Merge "removals: all unicode encoding / decoding" into mainmike bayer2021-11-118-158/+28
|\ \
| * | removals: all unicode encoding / decodingMike Bayer2021-11-108-158/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removed here includes: * convert_unicode parameters * encoding create_engine() parameter * description encoding support * "non-unicode fallback" modes under Python 2 * String symbols regarding Python 2 non-unicode fallbacks * any concept of DBAPIs that don't accept unicode statements, unicode bound parameters, or that return bytes for strings anywhere except an explicit Binary / BLOB type * unicode processors in Python / C Risk factors: * Whether all DBAPIs do in fact return Unicode objects for all entries in cursor.description now * There was logic for mysql-connector trying to determine description encoding. A quick test shows Unicode coming back but it's not clear if there are still edge cases where they return bytes. if so, these are bugs in that driver, and at most we would only work around it in the mysql-connector DBAPI itself (but we won't do that either). * It seems like Oracle 8 was not expecting unicode bound parameters. I'm assuming this was all Python 2 stuff and does not apply for modern cx_Oracle under Python 3. * third party dialects relying upon built in unicode encoding/decoding but it's hard to imagine any non-SQLAlchemy database driver not dealing exclusively in Python unicode strings in Python 3 Change-Id: I97d762ef6d4dd836487b714d57d8136d0310f28a References: #7257
* | | Merge "change the POSTCOMPILE/ SCHEMA symbols to not conflict w mssql ↵mike bayer2021-11-091-0/+3
|\ \ \ | |/ / |/| | | | | quoting" into main
| * | change the POSTCOMPILE/ SCHEMA symbols to not conflict w mssql quotingMike Bayer2021-11-091-0/+3
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjusted the compiler's generation of "post compile" symbols including those used for "expanding IN" as well as for the "schema translate map" to not be based directly on plain bracketed strings with underscores, as this conflicts directly with SQL Server's quoting format of also using brackets, which produces false matches when the compiler replaces "post compile" and "schema translate" symbols. The issue created easy to reproduce examples both with the :meth:`.Inspector.get_schema_names` method when used in conjunction with the :paramref:`_engine.Connection.execution_options.schema_translate_map` feature, as well in the unlikely case that a symbol overlapping with the internal name "POSTCOMPILE" would be used with a feature like "expanding in". Fixes: #7300 Change-Id: I6255c850b140522a4aba95085216d0bca18ce230
* | De-emphasize notion of "default driver" (DBAPI)Gord Thompson2021-11-095-9/+9
|/ | | | | | | | | | | Fixes: #6960 Even though a default driver still exists for each dialect, remove most usages of `dialect://` to encourage users to explicitly specify `dialect+driver://` Change-Id: I0ad42167582df509138fca64996bbb53e379b1af
* fully implement future engine and remove legacyMike Bayer2021-11-073-17/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | The major action here is to lift and move future.Connection and future.Engine fully into sqlalchemy.engine.base. This removes lots of engine concepts, including: * autocommit * Connection running without a transaction, autobegin is now present in all cases * most "autorollback" is obsolete * Core-level subtransactions (i.e. MarkerTransaction) * "branched" connections, copies of connections * execution_options() returns self, not a new connection * old argument formats, distill_params(), simplifies calling scheme between engine methods * before/after_execute() events (oriented towards compiled constructs) don't emit for exec_driver_sql(). before/after_cursor_execute() is still included for this * old helper methods superseded by context managers, connection.transaction(), engine.transaction() engine.run_callable() * ancient engine-level reflection methods has_table(), table_names() * sqlalchemy.testing.engines.proxying_engine References: #7257 Change-Id: Ib20ed816642d873b84221378a9ec34480e01e82c
* simplify and publicize the asyncpg JSON(B) codec registrsationMike Bayer2021-11-031-29/+55
| | | | | | | | | | | | Added overridable methods ``PGDialect_asyncpg.setup_asyncpg_json_codec`` and ``PGDialect_asyncpg.setup_asyncpg_jsonb_codec`` codec, which handle the required task of registering JSON/JSONB codecs for these datatypes when using asyncpg. The change is that methods are broken out as individual, overridable methods to support third party dialects that need to alter or disable how these particular codecs are set up. Fixes: #7284 Change-Id: I3eac258fea61f3975bd03c428747f788813ce45e
* Revert "Gracefully degrade unsupported types with asyncpg"mike bayer2021-11-031-29/+14
| | | | | | | | This reverts commit 96c294da8a50d692b3f0b8e508dbbca5d9c22f1b. I have another approach that is more obvious, easier to override explicitly and also I can test it more easily. Change-Id: I11a3be7700dbc6f25d436e450b6fb8e8f6c4fd16
* formatting updatesMike Bayer2021-11-031-2/+3
| | | | Change-Id: I7352bed0115b8fcdb4708e012d83e81d1ae494ed
* Merge "Gracefully degrade unsupported types with asyncpg" into mainmike bayer2021-11-031-14/+29
|\
| * Gracefully degrade unsupported types with asyncpgGord Thompson2021-11-021-14/+29
| | | | | | | | | | | | | | | | | | | | | | | | Fixes: #7284 Modify the on_connect() method of PGDialect_asyncpg to gracefully degrade unsupported types instead of throwing a ValueError. Useful for third-party dialects that derive from PGDialect_asyncpg but whose databases do not support all types (e.g., CockroachDB supports JSONB but not JSON). Change-Id: Ibb7cc8c3de632d27b9716a93d83956a590b2a2b0
* | Merge "Fixed issue in visit_on_duplicate_key_update within a composed ↵mike bayer2021-11-031-1/+1
|\ \ | | | | | | | | | expression" into main
| * | Fixed issue in visit_on_duplicate_key_update within a composed expressionCristian Sabaila2021-11-021-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue in MySQL :meth:`_mysql.Insert.on_duplicate_key_update` which would render the wrong column name when an expression were used in a VALUES expression. Pull request courtesy Cristian Sabaila. Fixes: #7281 Closes: #7285 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7285 Pull-request-sha: 3e6ad6f2fecc6ae36a10a5a34b5d3d393483edbb Change-Id: I83377c20eae6358fead9e7e361127938e538a71c
* | map Float to asyncpg.FLOAT, test for infinityMike Bayer2021-11-021-0/+9
|/ | | | | Fixes: #7283 Change-Id: I5402a72617b7f9bc366d64bc5ce8669374839984
* First round of removal of python 2Federico Caselli2021-11-016-158/+27
| | | | | References: #4600 Change-Id: I61e35bc93fe95610ae75b31c18a3282558cd4ffe
* Update psycopg2 dialect to use the DBAPI interface to executeFederico Caselli2021-10-312-10/+41
| | | | | | | two phase transactions Fixes: #7238 Change-Id: Ie4f5cf59d29b5bfc142ec2dfdecffb896ee7d708
* Merge "Remove deprecated dialects and drivers" into mainmike bayer2021-10-3118-3597/+5
|\
| * Remove deprecated dialects and driversFederico Caselli2021-10-3118-3597/+5
| | | | | | | | | | Fixes: #7258 Change-Id: I3577f665eca04f2632b69bcb090f0a4ec9271db9
* | The ``has_table`` method now also checks viewsFederico Caselli2021-10-312-4/+14
|/ | | | | | | | | | | | The :meth:`_engine.Inspector.has_table` method will now consistently check for views of the given name as well as tables. Previously this behavior was dialect dependent, with PostgreSQL, MySQL/MariaDB and SQLite supporting it, and Oracle and SQL Server not supporting it. Third party dialects should also seek to ensure their :meth:`_engine.Inspector.has_table` method searches for views as well as tables for the given name. Fixes: #7161 Change-Id: I9e523c76741b19596c81ef577dc6f0823e44183b
* Merge "Improve array support on pg8000" into mainmike bayer2021-10-282-1/+9
|\
| * Improve array support on pg8000Federico Caselli2021-10-272-1/+9
| | | | | | | | | | | | References: #6023 Change-Id: I0f6cbc34b3c0bfc0b8c86b3ebe4531e23039b6c0
* | Fixes: #5020jonathan vanasco2021-10-271-7/+68
| | | | | | | | | | | | Add mike's example to docs Change-Id: I96a79084cccca5c792bee697338422f3de0884fb
* | add additional "oracle mode" reserved wordsMike Bayer2021-10-261-3/+19
|/ | | | | | | | | | despite mariadb's docs, the word "system" must be quoted in plain mariadb 10.5, not sure if that's "oracle mode" but it is > 10.3. observed keystone tests failing on a column of this name. Fixes: #7167 Change-Id: I153b79809e7da007bcceecec96c1340d1641f0de
* fix: Update reserved words list of MySQL / MariaDB dialectKevin Kirsche2021-10-205-308/+563
| | | | | | | | | | | | | | | | | | | | | | | Reorganized the list of reserved words into two separate lists, one for MySQL and one for MariaDB, so that these diverging sets of words can be managed more accurately; adjusted the MySQL/MariaDB dialect to switch among these lists based on either explicitly configured or server-version-detected "MySQL" or "MariaDB" backend. Added all current reserved words through MySQL 8 and current MariaDB versions including recently added keywords like "lead" . Pull request courtesy Kevin Kirsche. 1. Move reserved words to it's own file. 2. Add missing reserved words from https://mariadb.com/kb/en/reserved-words/ * Note: this only adds MariaDB though links to MySQL, it also does not include the reserved words for Oracle mode, as listed in the link. Fixes: #7167 Supercedes: #7197 Closes: #7207 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7207 Pull-request-sha: 5a682e331069520ccad9e6bf3cc5e4a77a889ef0 Change-Id: Ib25be8148568899f56b5c9b42d4f530ade8a04e3
* re-enable asnycmy >= 0.2.3; disable aiomysql totallyMike Bayer2021-10-151-3/+6
| | | | Change-Id: I94bc22db0462509003c8241d0ccef915fe6513c6
* Merge "support bind expressions w/ expanding IN; apply to psycopg2" into mainmike bayer2021-10-153-21/+24
|\
| * support bind expressions w/ expanding IN; apply to psycopg2Mike Bayer2021-10-153-21/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where "expanding IN" would fail to function correctly with datatypes that use the :meth:`_types.TypeEngine.bind_expression` method, where the method would need to be applied to each element of the IN expression rather than the overall IN expression itself. Fixed issue where IN expressions against a series of array elements, as can be done with PostgreSQL, would fail to function correctly due to multiple issues within the "expanding IN" feature of SQLAlchemy Core that was standardized in version 1.4. The psycopg2 dialect now makes use of the :meth:`_types.TypeEngine.bind_expression` method with :class:`_types.ARRAY` to portably apply the correct casts to elements. The asyncpg dialect was not affected by this issue as it applies bind-level casts at the driver level rather than at the compiler level. as part of this commit the "bind translate" feature has been simplified and also applies to the names in the POSTCOMPILE tag to accommodate for brackets. Fixes: #7177 Change-Id: I08c703adb0a9bd6f5aeee5de3ff6f03cccdccdc5
* | Fix reflection of FK against a unique indexGord Thompson2021-10-141-24/+135
|/ | | | | | | | Also implement reflection of ON DELETE, ON UPDATE as the data is right there. Fixes: #7160 Change-Id: Ifff871a8cb1d1bea235616042e16ed3b5c5f19f9
* Fix has_table() false negative for #temp tablesGord Thompson2021-10-121-8/+12
| | | | | | | | | | | Fixed issue with :meth:`.Inspector.has_table` where it would return False if a local temp table with the same name from a different session happened to be returned first when querying tempdb. This is a continuation of :ticket:`6910` which accounted for the temp table existing only in the alternate session and not the current one. Fixes: #7168 Change-Id: I19dbb71a63184c6d41822b0e882b7b284ac83786
* Merge "Add autocommit documentation for Azure SQL DW"mike bayer2021-10-061-3/+42
|\
| * Add autocommit documentation for Azure SQL DWGord Thompson2021-09-281-3/+42
| | | | | | | | | | Fixes: #7065 Change-Id: I3666e16f9a8c47f9784ea11f38972cda6b08c146
* | Merge "Bugfix: MySQL expression: may be bindparam or other expression"mike bayer2021-10-051-1/+1
|\ \
| * | Bugfix: MySQL expression: may be bindparam or other expressionAnton Kovalevich2021-10-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue in MySQL :func:`_mysql.match` construct where passing a clause expression such as :func:`_sql.bindparam` or other SQL expression for the "against" parameter would fail. Pull request courtesy Anton Kovalevich. Fixes: #7144 Closes: #7145 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7145 Pull-request-sha: 3757ffa51a3ff5919278165aaf906c8d2f9940c0 Change-Id: I7bb95f338afe3a17296a7b60e8c973f93b4f5e62
* | | Handle SSL SYSCALL error: Bad Address in postgresql/pyscopg2Zeke Brechtel2021-10-051-1/+2
|/ / | | | | | | | | | | | | | | | | | | | | | | Added a "disconnect" condition for the "SSL SYSCALL error: Bad address" error message as reported by psycopg2. Pull request courtesy Zeke Brechtel. Fixes: #5387 Closes: #7087 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7087 Pull-request-sha: 66af76a107a22d9119edc8edcacc1e4ef66dc50d Change-Id: Ia4afc9683b8175a8ca282e07e0f83c65657544ab
* | repair any_() / all_() "implicit flip" behavior for NoneMike Bayer2021-10-041-14/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed an inconsistency in the any_() / all_() functions / methods where the special behavior these functions have of "flipping" the expression such that the "ANY" / "ALL" expression is always on the right side would not function if the comparison were against the None value, that is, "column.any_() == None" should produce the same SQL expression as "null() == column.any_()". Added more docs to clarify this as well, plus mentions that any_() / all_() generally supersede the ARRAY version "any()" / "all()". Fixes: #7140 Change-Id: Ia5d55414ba40eb3fbda3598931fdd24c9b4a4411
* | Merge "Fixes: #3160"mike bayer2021-10-011-6/+25
|\ \
| * | Fixes: #3160jonathan vanasco2021-09-281-6/+25
| |/ | | | | | | | | | | | | Clarify that match() emits `to_tsquery`, which expects input text to be in postgresql's own format. Change-Id: Id723032bca2eededc03ac30681c0dd4ddf76c232
* | organize datetime types for correct implsMike Bayer2021-10-012-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed bug in SQL Server ``DATETIMEOFFSET`` where the ODBC implementation would not generate the correct DDL, for cases where the type were converted using the ``dialect.type_descriptor()`` method, the usage of which is illustrated in some documented examples for :class:`.TypeDecorator`, though not necessary for most datatypes. Regression was introduced by :ticket:`6366`. As part of this change, the full list of SQL Server date types have been amended to return a "dialect impl" that generates the same DDL name as the supertype. Fixes: #7129 Change-Id: I7d9bea54c0c38e16d1a6ad978cca996006a1b624
* | correct charset for mariadb connector with mdb 10.6Georg Richter2021-10-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updated test suite to pass correctly for MariaDB 10.6 when using the mariadb-connector driver, which made some adjustments to default encoding. Pull request courtesy Georg Richter. Use character set utf8mb4 instead of utf8: 1) Character set for mariadb connector is utf8mb4 and cannot be changed. 2) Since MariaDB 10.6.1 utf8 is mapped to utf8mb3, and will be mapped to utf8mb4 in 10.7, see [MDEV-8334](https://jira.mariadb.org/browse/MDEV-8334) (rename utf8 to utf8mb3) utf8mb4 character set support was added 12 years ago and will work with all non eoled MariaDB server versions. Fixes: #7115 Closes: #7116 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7116 Pull-request-sha: 79516ccce2dead11e6658596c9ad400b964d24c9 Change-Id: I86c30fb636c46307cb551080641e324d2bbc1cb3
* | Fixes: #2937jonathan vanasco2021-09-281-1/+35
|/ | | | | | | * docs for event listen kwargs * docs for mysql to use `listen` for changing the sql_mode` Change-Id: I7c1678488658edda3c5baaf0f7648108e93a4be1
* Merge "pin asyncmy>=0.2.0 and remove cursor close workarounds"mike bayer2021-09-181-18/+4
|\
| * pin asyncmy>=0.2.0 and remove cursor close workaroundsMike Bayer2021-09-181-18/+4
| | | | | | | | Change-Id: I9426e09e4fd21f9c94f3c89b199a7784d33b949f
* | Surface driver connection object when using a proxied dialectFederico Caselli2021-09-179-19/+35
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Improve the interface used by adapted drivers, like the asyncio ones, to access the actual connection object returned by the driver. The :class:`_engine._ConnectionRecord` and :class:`_engine._ConnectionFairy` now have two new attributes: * ``dbapi_connection`` always represents a DBAPI compatible object. For pep-249 drivers, this is the DBAPI connection as it always has been, previously accessed under the ``.connection`` attribute. For asyncio drivers that SQLAlchemy adapts into a pep-249 interface, the returned object will normally be a SQLAlchemy adaption object called :class:`_engine.AdaptedConnection`. * ``driver_connection`` always represents the actual connection object maintained by the third party pep-249 DBAPI or async driver in use. For standard pep-249 DBAPIs, this will always be the same object as that of the ``dbapi_connection``. For an asyncio driver, it will be the underlying asyncio-only connection object. The ``.connection`` attribute remains available and is now a legacy alias of ``.dbapi_connection``. Fixes: #6832 Change-Id: Ib72f97deefca96dce4e61e7c38ba430068d6a82e
View Lorry Controller Status