summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/dialects
Commit message (Collapse)AuthorAgeFilesLines
* remove all labels and links that are no longer locatableMike Bayer2023-04-2315-30/+30
| | | | Change-Id: Ic975b8c20bc297d3a04dde0bed143783ae951cd4
* changelog fixes; editsMike Bayer2023-04-212-5/+9
| | | | Change-Id: I6bbef2416f864d1414d56f9bf39026156aed5e67
* Merge "Add name_func optional attribute for asyncpg adapter" into mainFederico Caselli2023-04-211-3/+67
|\
| * Add name_func optional attribute for asyncpg adapterPavel Sirotkin2023-04-211-3/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I faced an issue related to pg bouncer and prepared statement cache flow in asyncpg dialect. Regarding this discussion https://github.com/sqlalchemy/sqlalchemy/issues/6467 I prepared PR to support an optional parameter `name` in prepared statement which is allowed, since 0.25.0 version in `asyncpg` https://github.com/MagicStack/asyncpg/pull/846 **UPD:** the issue with proposal: https://github.com/sqlalchemy/sqlalchemy/issues/9608 ### Description Added optional parameter `name_func` to `AsyncAdapt_asyncpg_connection` class which will call on the `self._connection.prepare()` function and populate a unique name. so in general instead this ```python from uuid import uuid4 from asyncpg import Connection class CConnection(Connection): def _get_unique_id(self, prefix: str) -> str: return f'__asyncpg_{prefix}_{uuid4()}__' engine = create_async_engine(..., connect_args={ 'connection_class': CConnection, }, ) ``` would be enough ```python from uuid import uuid4 engine = create_async_engine(..., connect_args={ 'name_func': lambda: f'__asyncpg_{uuid4()}__', }, ) ``` ### Checklist <!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once) --> This pull request is: - [ ] A documentation / typographical error fix - Good to go, no issue or tests are needed - [ ] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [x] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. **Have a nice day!** Fixes: #9608 Closes: #9607 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9607 Pull-request-sha: b4bc8d3e57ab095a26112830ad4bea36083454e3 Change-Id: Icd753366cba166b8a60d1c8566377ec8335cd828
* | Merge "add deterministic imv returning ordering using sentinel columns" into ↵mike bayer2023-04-219-58/+139
|\ \ | | | | | | | | | main
| * | add deterministic imv returning ordering using sentinel columnsMike Bayer2023-04-219-58/+139
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repaired a major shortcoming which was identified in the :ref:`engine_insertmanyvalues` performance optimization feature first introduced in the 2.0 series. This was a continuation of the change in 2.0.9 which disabled the SQL Server version of the feature due to a reliance in the ORM on apparent row ordering that is not guaranteed to take place. The fix applies new logic to all "insertmanyvalues" operations, which takes effect when a new parameter :paramref:`_dml.Insert.returning.sort_by_parameter_order` on the :meth:`_dml.Insert.returning` or :meth:`_dml.UpdateBase.return_defaults` methods, that through a combination of alternate SQL forms, direct correspondence of client side parameters, and in some cases downgrading to running row-at-a-time, will apply sorting to each batch of returned rows using correspondence to primary key or other unique values in each row which can be correlated to the input data. Performance impact is expected to be minimal as nearly all common primary key scenarios are suitable for parameter-ordered batching to be achieved for all backends other than SQLite, while "row-at-a-time" mode operates with a bare minimum of Python overhead compared to the very heavyweight approaches used in the 1.x series. For SQLite, there is no difference in performance when "row-at-a-time" mode is used. It's anticipated that with an efficient "row-at-a-time" INSERT with RETURNING batching capability, the "insertmanyvalues" feature can be later be more easily generalized to third party backends that include RETURNING support but not necessarily easy ways to guarantee a correspondence with parameter order. Fixes: #9618 References: #9603 Change-Id: I1d79353f5f19638f752936ba1c35e4dc235a8b7c
* | Add intersection method to Range classYurii Karabas2023-04-141-0/+46
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <!-- Provide a general summary of your proposed changes in the Title field above --> ### Description Fixes: #9509 <!-- Describe your changes in detail --> ### Checklist <!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once) --> This pull request is: - [ ] A documentation / typographical error fix - Good to go, no issue or tests are needed - [ ] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [x] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. **Have a nice day!** Closes: #9510 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9510 Pull-request-sha: 596648e7989327eef1807057519b2295b48f1adf Change-Id: I7b527edda09eb78dee6948edd4d49b00ea437011
* Remove old versionadded and versionchangedFederico Caselli2023-04-1216-137/+1
| | | | | | | Removed versionadded and versionchanged for version prior to 1.2 since they are no longer useful. Change-Id: I5c53d1188bc5fec3ab4be39ef761650ed8fa6d3e
* Merge "Fix reflection of long expressions in postgresql" into mainmike bayer2023-04-091-4/+11
|\
| * Fix reflection of long expressions in postgresqlFederico Caselli2023-04-071-4/+11
| | | | | | | | | | | | | | | | | | Fixed issue that prevented reflection of expression based indexes with long expressions in PostgreSQL. The expression where erroneously truncated to the identifier length (that's 63 bytes by default). Fixes: #9615 Change-Id: I50727b0699e08fa25f10f3c94dcf8b79534bfb75
* | fix pg ENUM issuesMike Bayer2023-04-081-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restored the :paramref:`_postgresql.ENUM.name` parameter as optional in the signature for :class:`_postgresql.ENUM`, as this is chosen automatically from a given pep-435 ``Enum`` type. Fixed issue where the comparison for :class:`_postgresql.ENUM` against a plain string would cast that right-hand side type as VARCHAR, which due to more explicit casting added to dialects such as asyncpg would produce a PostgreSQL type mismatch error. Fixes: #9611 Fixes: #9621 Change-Id: If095544cd1a52016ad2e7cfa2d70c919a94e79c1
* | walk back SQL Server language a bit re: insertmanyvaluesMike Bayer2023-04-071-3/+4
|/ | | | | | | | | | | | | In #9618 we both can look to re-enable insertmanyvalues for SQL Server, and also likely *disable* its use for the ORM unit of work specifically, since that's really where the only problem is, and it will likely be for all dialects, not just SQL Server. An approach using sentinel columns will be rolled out for the unit of work use case. Change-Id: I3358e30839491769db95b4ac042a661271df3929 References: #9618 References: #9603
* Fix typos in PostgreSQL dialect’s DOMAIN docs (#9601)Jens Tröger2023-04-061-2/+2
|
* turn off use_insertmanyvalues for SQL ServerMike Bayer2023-04-052-26/+22
| | | | | | | | | | | | | | | | | | we will keep trying to find workarounds, however this patch is the "turn it off" patch Due to a critical bug identified in SQL Server, the SQLAlchemy "insertmanyvalues" feature which allows fast INSERT of many rows while also supporting RETURNING unfortunately needs to be disabled for SQL Server. SQL Server is apparently unable to guarantee that the order of rows inserted matches the order in which they are sent back by OUTPUT inserted when table-valued rows are used with INSERT in conjunction with OUTPUT inserted. We are trying to see if Microsoft is able to confirm this undocumented behavior however there is no known workaround, other than it's not safe to use table-valued expressions with OUTPUT inserted for now. Fixes: #9603 Change-Id: I4b932fb8774390bbdf4e870a1f6cfe9a78c4b105
* Merge "Added ``row_number`` as reserved word in MariaDb." into mainmike bayer2023-04-021-0/+1
|\
| * Added ``row_number`` as reserved word in MariaDb.Federico Caselli2023-04-021-0/+1
| | | | | | | | | | | | Fixes: #9588 References: #9585 Change-Id: Ic6668311ea488339023d7aab1a186f8465131fd8
* | favor fast_executemany over insertmanyvalues when setMike Bayer2023-04-022-5/+13
|/ | | | | | | | | | | | | | | | | | | | | | | Changed the bulk INSERT strategy used for SQL Server "executemany" with pyodbc when ``fast_executemany`` is set to ``True`` by using ``fast_executemany`` / ``cursor.executemany()`` for bulk INSERT that does not include RETURNING, restoring the same behavior as was used in SQLAlchemy 1.4 when this parameter is set. For INSERT statements that use RETURNING, the "insertmanyvalues" strategy continues to be used as it is the only current strategy that supports RETURNING with bulk INSERT. Previously, SQLAlchemy 2.0 would use "insertmanyvalues" for all INSERT statements when ``use_insertmanyvalues`` was left at its default of ``False``, ignoring if ``fast_executemany`` was set. New performance details from end users have shown that ``fast_executemany`` is still much faster for very large datasets as it uses ODBC commands that can receive all rows in a single round trip, allowing for much larger datasizes than the batches that can be sent by the current "insertmanyvalues" strategy. Fixes: #9586 Change-Id: I85955a10ba77c26cdc0c22e362a827d7aaef2852
* Fix creating zero length char with MySQL dialectJ. Nick Koston2023-03-271-6/+6
| | | | | | | | | | | | | | Fixed issue where string datatypes such as :class:`.CHAR`, :class:`.VARCHAR`, :class:`.TEXT`, as well as binary :class:`.BLOB`, could not be produced with an explicit length of zero, which has special meaning for MySQL. Pull request courtesy J. Nick Koston. Fixes: #9544 Closes: #9543 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9543 Pull-request-sha: dc17fc3e93f0ba90881c4efb06016ddf83c7af8b Change-Id: I96925d45f16887f5dfd68a5d4f9284b3abc46d25
* Merge "automatically provision hstore for pg13+" into mainmike bayer2023-03-251-3/+12
|\
| * automatically provision hstore for pg13+Federico Caselli2023-03-151-3/+12
| | | | | | | | Change-Id: I5cd7e9e9ab8a1dae2bd467a1e4299d7f26183301
* | dont render VARCHAR length for PG castsMike Bayer2023-03-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed critical regression in PostgreSQL dialects such as asyncpg which rely upon explicit casts in SQL in order for datatypes to be passed to the driver correctly, where a :class:`.String` datatype would be cast along with the exact column length being compared, leading to implicit truncation when comparing a ``VARCHAR`` of a smaller length to a string of greater length regardless of operator in use (e.g. LIKE, MATCH, etc.). The PostgreSQL dialect now omits the length from ``VARCHAR`` when rendering these casts. Fixes: #9511 Change-Id: If094146d8cfd989a0b780872f38e86fd41ebfec2
* | Merge "Add override hook PGDialect.set_backslash_escapes()" into mainmike bayer2023-03-151-4/+9
|\ \ | |/ |/|
| * Add override hook PGDialect.set_backslash_escapes()Matt del Valle2023-03-131-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Description Refactor out the lines in `PGDialect.initialize()` that set backslash escapes into their own method to provide an override hook for [`sqlalchemy-redshift`](https://github.com/sqlalchemy-redshift/sqlalchemy-redshift) to use. Fixes #9442 ### Checklist This pull request is: - [ ] A documentation / typographical error fix - Good to go, no issue or tests are needed - [x] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [ ] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. Closes: #9475 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9475 Pull-request-sha: 5565afeac20ea3612c3f427f58efacd8487ac159 Change-Id: I9b652044243ab231c19ab55ebc8ee24534365d61
* | Implementation of CITEXT , unittest and documentationJulian David Rath2023-03-154-10/+27
|/ | | | | | | | | | | | Added new PostgreSQL type :class:`_postgresql.CITEXT`. Pull request courtesy Julian David Rath. Fixes: #9416 Closes: #9417 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9417 Pull-request-sha: 23a83a342ad6d820ee5749ebccda04e54c373f7d Change-Id: I54699b9457426c20afbdc0acaa41dc57644b0536
* sqlite provisioning is ridiculousMike Bayer2023-03-101-74/+96
| | | | | | try to get file naming to be more sane for pysqlite file databases Change-Id: I68ad8c2f6c6c25930fbffdd79b8d429cd7a7dd9a
* denormalize "public" schema to "PUBLIC"Mike Bayer2023-03-091-17/+45
| | | | | | | | | | | | | Fixed reflection bug where Oracle "name normalize" would not work correctly for reflection of symbols that are in the "PUBLIC" schema, such as synonyms, meaning the PUBLIC name could not be indicated as lower case on the Python side for the :paramref:`_schema.Table.schema` argument. Using uppercase "PUBLIC" would work, but would then lead to awkward SQL queries including a quoted ``"PUBLIC"`` name as well as indexing the table under uppercase "PUBLIC", which was inconsistent. Fixes: #9459 Change-Id: I989bd1e794a5b5ac9aae4f4a8702f14c56cd74c2
* update sql server use_setinputsizes docs a bitMike Bayer2023-03-061-7/+10
| | | | | | the verbiage here was ambiguous previously. Change-Id: I452ae85bd8b5469d4103970e99cfac752b508274
* Merge "audition pymssql once more; retire sane_rowcount_returning" into mainmike bayer2023-03-055-32/+48
|\
| * audition pymssql once more; retire sane_rowcount_returningMike Bayer2023-03-045-32/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pymssql seems to be maintained again and seems to be working completely, so let's try re-enabling it. Fixed issue in the new :class:`.Uuid` datatype which prevented it from working with the pymssql driver. As pymssql seems to be maintained again, restored testing support for pymssql. Tweaked the pymssql dialect to take better advantage of RETURNING for INSERT statements in order to retrieve last inserted primary key values, in the same way as occurs for the mssql+pyodbc dialect right now. Identified that the ``sqlite`` and ``mssql+pyodbc`` dialects are now compatible with the SQLAlchemy ORM's "versioned rows" feature, since SQLAlchemy now computes rowcount for a RETURNING statement in this specific case by counting the rows returned, rather than relying upon ``cursor.rowcount``. In particular, the ORM versioned rows use case (documented at :ref:`mapper_version_counter`) should now be fully supported with the SQL Server pyodbc dialect. Change-Id: I38a0666587212327aecf8f98e86031ab25d1f14d References: #5321 Fixes: #9414
* | Merge "ensure event handlers called for all do_ping" into mainmike bayer2023-03-054-43/+17
|\ \
| * | ensure event handlers called for all do_pingMike Bayer2023-03-044-43/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The support for pool ping listeners to receive exception events via the :meth:`.ConnectionEvents.handle_error` event added in 2.0.0b1 for :ticket:`5648` failed to take into account dialect-specific ping routines such as that of MySQL and PostgreSQL. The dialect feature has been reworked so that all dialects participate within event handling. Additionally, a new boolean element :attr:`.ExceptionContext.is_pre_ping` is added which identifies if this operation is occurring within the pre-ping operation. For this release, third party dialects which implement a custom :meth:`_engine.Dialect.do_ping` method can opt in to the newly improved behavior by having their method no longer catch exceptions or check exceptions for "is_disconnect", instead just propagating all exceptions outwards. Checking the exception for "is_disconnect" is now done by an enclosing method on the default dialect, which ensures that the event hook is invoked for all exception scenarios before testing the exception as a "disconnect" exception. If an existing ``do_ping()`` method continues to catch exceptions and check "is_disconnect", it will continue to work as it did previously, but ``handle_error`` hooks will not have access to the exception if it isn't propagated outwards. Fixes: #5648 Change-Id: I6535d5cb389e1a761aad8c37cfeb332c548b876d
* | | Merge "Restore connectivity with ancient sqlite" into mainmike bayer2023-03-041-1/+8
|\ \ \ | |_|/ |/| |
| * | Restore connectivity with ancient sqliteFederico Caselli2023-03-041-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | Fixed bug that prevented SQLAlchemy to connect when using a very old sqlite version (before 3.9) on python 3.8+. Fixes: #9379 Change-Id: I10ca347398221c952e1a572dc6ef80e491d1f5cf
* | | Fixed issue when copying ExcludeConstraintFederico Caselli2023-03-011-7/+4
| | | | | | | | | | | | | | | Fixes: #9401 Change-Id: Ie10192348749567110f53ae618fc724f37d1a6a1
* | | Improve exclude constraint docs and tests.Federico Caselli2023-02-271-5/+9
|/ / | | | | | | | | | | Follow up of 71693c94d52612a5e88128575ff308ee4a923c00 Change-Id: Icc9d9942bda92171581dec82cf0cacbd3e3e4162
* | ExcludeConstraint literal_compileFederico Caselli2023-02-222-9/+9
|/ | | | | | | | ExcludeConstraint correctly uses literal compile when compiling expression ddl. Fixes: #9349 Change-Id: I11a994ac46556a972afc696a2baad7ddbdd3de97
* Improve ``oracledb`` thick mode flag.Federico Caselli2023-02-141-1/+3
| | | | | | | | Adjusted ``oracledb`` thick mode flag to make ``thick_mode=False`` not enable thick mode. Previously only ``None`` was accepted as off value. Fixes: #9295 Change-Id: I1a8397c19d065dfc2dda597e719922fc8d31acb1
* Remove `typing.Self` workaroundYurii Karabas2023-02-084-32/+16
| | | | | | | | | | | | Remove ``typing.Self`` workaround, now using :pep:`673` for most methods that return ``Self``. Pull request courtesy Yurii Karabas. Fixes: #9254 Closes: #9255 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9255 Pull-request-sha: 2947df8ada79f5c3afe9c838e65993302199c2f7 Change-Id: Ic32015ad52e95a61f3913d43ea436aa9402804df
* Merge "add error code 1049 for mysql has_table" into mainFederico Caselli2023-02-062-1/+20
|\
| * add error code 1049 for mysql has_tableMike Bayer2023-02-062-1/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression caused by issue :ticket:`9058` which adjusted the MySQL dialect's ``has_table()`` to again use "DESCRIBE", where the specific error code raised by MySQL version 8 when using a non-existent schema name was unexpected and failed to be interpreted as a boolean result. Fixed the SQLite dialect's ``has_table()`` function to correctly report False for queries that include a non-None schema name for a schema that doesn't exist; previously, a database error was raised. Fixes: #9251 Change-Id: I5ef9cf0887865c3c521d88bca0ba18954a108241
* | Merge "Dedicated bitwise operators" into mainmike bayer2023-02-061-0/+3
|\ \
| * | Dedicated bitwise operatorsjazzthief2023-02-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added a full suite of new SQL bitwise operators, for performing database-side bitwise expressions on appropriate data values such as integers, bit-strings, and similar. Pull request courtesy Yegor Statkevich. Fixes: #8780 Closes: #9204 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9204 Pull-request-sha: a4541772a6a784f9161ad78ef84d2ea7a62fa8de Change-Id: I4c70e80f9548dcc1b4e3dccd71bd59d51d3ed46e
* | | Merge "use mysql 8 syntax for ON DUPLICATE KEY UPDATE" into mainmike bayer2023-02-061-7/+35
|\ \ \ | |_|/ |/| |
| * | use mysql 8 syntax for ON DUPLICATE KEY UPDATECaspar Wylie2023-02-061-7/+35
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added support for MySQL 8's new ``AS <name> ON DUPLICATE KEY`` syntax when using :meth:`_mysql.Insert.on_duplicate_key_update`, which is required for newer versions of MySQL 8 as the previous syntax using ``VALUES()`` now emits a deprecation warning with those versions. Server version detection is employed to determine if traditional MariaDB / MySQL < 8 ``VALUES()`` syntax should be used, vs. the newer MySQL 8 required syntax. Pull request courtesy Caspar Wylie. Fixes: #8626 Closes: #9210 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9210 Pull-request-sha: 1c8dfbf0b4c439d9ca2c194524c47eb7239ee3c5 Change-Id: I42c463837af06bc15b60c534159804193df07f02
* | Use correct dialect annotationFederico Caselli2023-02-021-1/+4
|/ | | | | Fixes: #9222 Change-Id: Ife841a5cf5ec896405e84d8570ef63ce6176a5ec
* Unify doc typingHarry Lees2023-01-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Description <!-- Describe your changes in detail --> Fixes #9168 This PR replaces common occurrences of [PEP 585](https://peps.python.org/pep-0585/) style type annotations with annotations compatible with older versions of Python. I searched for instances of the following supported types from the PEP and replaced with their legacy typing couterparts. * tuple # typing.Tuple * list # typing.List * dict # typing.Dict * set # typing.Set * frozenset # typing.FrozenSet * type # typing.Type ``` grep -r "list\[.*\]" ./build --exclude-dir="./build/venv/*" --exclude-dir="./build/output/*" --exclude="changelog_[0-9]*\.rst" ``` I excluded changelog files from being altered, I think some of these could be changed if necessary but others are likely to require manual checking as the change may target the new typing style specifically. For any examples that included imports, I tried to ensure that the correct typing imports were included and properly ordered. ### Checklist <!-- go over following points. check them with an `x` if they do apply, (they turn into clickable checkboxes once the PR is submitted, so no need to do everything at once) --> This pull request is: - [x] A documentation / typographical error fix - Good to go, no issue or tests are needed - [ ] A short code fix - please include the issue number, and create an issue if none exists, which must include a complete example of the issue. one line code fixes without an issue and demonstration will not be accepted. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. one line code fixes without tests will not be accepted. - [ ] A new feature implementation - please include the issue number, and create an issue if none exists, which must include a complete example of how the feature would look. - Please include: `Fixes: #<issue number>` in the commit message - please include tests. Closes: #9198 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9198 Pull-request-sha: 05ad4651b57c6275b29433e5e76e166344ba6c4c Change-Id: I41b93b3dee85f9fe00cfbb3d3eb011212795de29
* Make comment support conditional on fn_listextendedproperty availabilityMike Bayer2023-01-251-0/+50
| | | | | | | | | | | | | | | The newly added comment reflection and rendering capability of the MSSQL dialect, added in :ticket:`7844`, will now be disabled by default if it cannot be determined that an unsupported backend such as Azure Synapse may be in use; this backend does not support table and column comments and does not support the SQL Server routines in use to generate them as well as to reflect them. A new parameter ``supports_comments`` is added to the dialect which defaults to ``None``, indicating that comment support should be auto-detected. When set to ``True`` or ``False``, the comment support is either enabled or disabled unconditionally. Fixes: #9142 Change-Id: Ib5cac31806185e7353e15b3d83b580652d304b3b
* reflect Oracle ROWIDMike Bayer2023-01-241-0/+1
| | | | | | | | Added :class:`_oracle.ROWID` to reflected types as this type may be used in a "CREATE TABLE" statement. Fixes: #5047 Change-Id: I818dcf68ed81419d0fd5df5e2d51d6fa0f1be7fc
* Run bracket interpretation for reflectionShan2023-01-231-3/+1
| | | | | | | | | | | | | | | | | | | | | Fixed bug where a schema name given with brackets, but no dots inside the name, for parameters such as :paramref:`_schema.Table.schema` would not be interpreted within the context of the SQL Server dialect's documented behavior of interpreting explicit brackets as token delimiters, first added in 1.2 for #2626, when referring to the schema name in reflection operations. The original assumption for #2626's behavior was that the special interpretation of brackets was only significant if dots were present, however in practice, the brackets are not included as part of the identifier name for all SQL rendering operations since these are not valid characters within regular or delimited identifiers. Pull request courtesy Shan. Fixes: #9133 Closes: #9134 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9134 Pull-request-sha: 5dac87c82cd3063dd8e50f0075c7c00330be6439 Change-Id: I7a507bc38d75a04ffcb7e920298775baae22c6d1
* pass driver_connection to TypeInfo.fetch()Mike Bayer2023-01-171-2/+2
| | | | | | | | | Fixed regression where psycopg3 changed an API call as of version 3.1.8 to expect a specific object type that was previously not enforced, breaking connectivity for the psycopg3 dialect. Fixes: #9106 Change-Id: Ibb42f84b1086f30173aeb6e1f3256c56d129fe6e
View Lorry Controller Status