summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/dialects/mysql
Commit message (Collapse)AuthorAgeFilesLines
* Merge "implement FromLinter for UPDATE, DELETE statements" into mainmike bayer2023-05-091-2/+2
|\
| * implement FromLinter for UPDATE, DELETE statementsMike Bayer2023-05-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implemented the "cartesian product warning" for UPDATE and DELETE statements, those which include multiple tables that are not correlated together in some way. Fixed issue where :func:`_dml.update` construct that included multiple tables and no VALUES clause would raise with an internal error. Current behavior for :class:`_dml.Update` with no values is to generate a SQL UPDATE statement with an empty "set" clause, so this has been made consistent for this specific sub-case. Fixes: #9721 Change-Id: I556639811cc930d2e37532965d2ae751882af921
* | Support control char reflection in mysql mariadbFederico Caselli2023-04-301-11/+29
|/ | | | | | | | | | | | Fixed issues regarding reflection of comments for :class:`_schema.Table` and :class:`_schema.Column` objects, where the comments contained control characters such as newlines. Additional testing support for these characters as well as extended Unicode characters in table and column comments (the latter of which aren't supported by MySQL/MariaDB) added to testing overall. Fixes: #9722 Change-Id: Id18bf758fdb6231eb705c61eeaf74bb9fa472601
* disable "bytes" handler for all drivers other than psycopg2J. Nick Koston2023-04-251-0/+2
| | | | | | | | | | | | | | | Improved row processing performance for "binary" datatypes by making the "bytes" handler conditional on a per driver basis. As a result, the "bytes" result handler has been disabled for nearly all drivers other than psycopg2, all of which in modern forms support returning Python "bytes" directly. Pull request courtesy J. Nick Koston. Fixes: #9680 Closes: #9681 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/9681 Pull-request-sha: 4f2fd88bd9af54c54438a3b72a2f30384b0f8898 Change-Id: I394bdcbebaab272e63b13cc02f60813b7aa76839
* add deterministic imv returning ordering using sentinel columnsMike Bayer2023-04-212-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove old versionadded and versionchangedFederico Caselli2023-04-123-11/+0
| | | | | | | Removed versionadded and versionchanged for version prior to 1.2 since they are no longer useful. Change-Id: I5c53d1188bc5fec3ab4be39ef761650ed8fa6d3e
* Added ``row_number`` as reserved word in MariaDb.Federico Caselli2023-04-021-0/+1
| | | | | | Fixes: #9588 References: #9585 Change-Id: Ic6668311ea488339023d7aab1a186f8465131fd8
* 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
* ensure event handlers called for all do_pingMike Bayer2023-03-042-18/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove `typing.Self` workaroundYurii Karabas2023-02-082-14/+6
| | | | | | | | | | | | 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-061-1/+15
|\
| * add error code 1049 for mysql has_tableMike Bayer2023-02-061-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | 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
* Merge "Improve sql formatting" into mainmike bayer2023-01-121-4/+4
|\
| * Improve sql formattingFederico Caselli2023-01-111-4/+4
| | | | | | | | | | | | change {opensql} to {printsql} in prints, add missing markers Change-Id: I07b72e6620bb64e329d6b641afa27631e91c4f16
* | Move docs in mysql dbapiFederico Caselli2023-01-112-14/+13
|/ | | | | Fixes: #9084 Change-Id: I5e174c318a20b7fcb5ea7c771293c5102e761ed7
* Merge "revert MySQL to use DESCRIBE for has_table()" into mainmike bayer2023-01-051-16/+23
|\
| * revert MySQL to use DESCRIBE for has_table()Mike Bayer2023-01-051-16/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Restored the behavior of :meth:`.Inspector.has_table` to report on temporary tables for MySQL / MariaDB. This is currently the behavior for all other included dialects, but was removed for MySQL in 1.4 due to no longer using the DESCRIBE command; there was no documented support for temp tables being reported by the :meth:`.Inspector.has_table` method in this version or on any previous version, so the previous behavior was undefined. As SQLAlchemy 2.0 has added formal support for temp table status via :meth:`.Inspector.has_table`, the MySQL /MariaDB dialect has been reverted to use the "DESCRIBE" statement as it did in the SQLAlchemy 1.3 series and previously, and test support is added to include MySQL / MariaDB for this behavior. The previous issues with ROLLBACK being emitted which 1.4 sought to improve upon don't apply in SQLAlchemy 2.0 due to simplifications in how :class:`.Connection` handles transactions. DESCRIBE is necessary as MariaDB in particular has no consistently available public information schema of any kind in order to report on temp tables other than DESCRIBE/SHOW COLUMNS, which rely on throwing an error in order to report no results. Fixes: #9058 Change-Id: Ic511bd5989ec17beb37b7cddd913732b626af0e6
* | include parsed col length field as integer from mysql index reflectionMike Bayer2023-01-042-3/+16
|/ | | | | | | | Added support to MySQL index reflection to correctly reflect the ``mysql_length`` dictionary, which previously was being ignored. Fixes: #9047 Change-Id: I0a5e27123be68741e12af4464a0fa305052ec36e
* happy new year 2023Mike Bayer2023-01-0317-17/+17
| | | | Change-Id: I625af65b3fb1815b1af17dc2ef47dd697fdc3fb1
* dont prefix ssl args with "ssl" in the ssl dictMike Bayer2022-12-271-3/+3
| | | | | Fixes: #9031 Change-Id: I9ef077e7da5b2328a345f6526a6210ce82d807f6
* ensure all visit methods accept **kwMike Bayer2022-12-161-7/+7
| | | | | | | | | | Added test support to ensure that all compiler ``visit_xyz()`` methods across all :class:`.Compiler` implementations in SQLAlchemy accept a ``**kw`` parameter, so that all compilers accept additional keyword arguments under all circumstances. Fixes: #8988 Change-Id: I1cefc313e4e64a10ee7dd14400137fbe02ce9523
* Try running pyupgrade on the codeFederico Caselli2022-11-1612-92/+66
| | | | | | | | command run is "pyupgrade --py37-plus --keep-runtime-typing --keep-percent-format <files...>" pyupgrade will change assert_ to assertTrue. That was reverted since assertTrue does not exists in sqlalchemy fixtures Change-Id: Ie1ed2675c7b11d893d78e028aad0d1576baebb55
* adjust MySQL view reflection for non-standard MySQL variantsJohn Bodley2022-10-032-1/+6
| | | | | | | | | | | | | | | | Adjusted the regular expression used to match "CREATE VIEW" when testing for views to work more flexibly, no longer requiring the special keyword "ALGORITHM" in the middle, which was intended to be optional but was not working correctly. The change allows view reflection to work more completely on MySQL-compatible variants such as StarRocks. Pull request courtesy John Bodley. Fixes: #8588 Closes: #8589 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8589 Pull-request-sha: d85b2c5b51e45cec543c9ae9d62d6d659b063354 Change-Id: I173137f0bf68639cad0d5c329055475b40ddb5e4
* implement batched INSERT..VALUES () () for executemanyMike Bayer2022-09-242-0/+19
| | | | | | | | | | | | | | | | | | | | the feature is enabled for all built in backends when RETURNING is used, except for Oracle that doesn't need it, and on psycopg2 and mssql+pyodbc it is used for all INSERT statements, not just those that use RETURNING. third party dialects would need to opt in to the new feature by setting use_insertmanyvalues to True. Also adds dialect-level guards against using returning with executemany where we dont have an implementation to suit it. execute single w/ returning still defers to the server without us checking. Fixes: #6047 Fixes: #7907 Change-Id: I3936d3c00003f02e322f2e43fb949d0e6e568304
* Support GROUP BY ROLLUP on MySql/MariaDBFederico Caselli2022-09-091-0/+6
| | | | | | | | | The ``ROLLUP`` function will now correctly render ``WITH ROLLUP`` on MySql and MariaDB, allowing the use of group by rollup with these backend. Fixes: #8503 Change-Id: I9289af3a39ca667a2f0f84f73346ebd4b091fedd
* Add support for Partitioning and Sample pages on mysqlRamonWill2022-08-111-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | Add support for Partitioning and Sample pages on MySQL and MariaDB reflected options. The options are stored in the table dialect options dictionary, so the following keyword need to be prefixed with ``mysql_`` or ``mariadb_`` depending on the backend. Supported options are: * ``stats_sample_pages`` * ``partition_by`` * ``partitions`` * ``subpartition_by`` These options are also reflected when loading a table from database, and will populate the table :attr:`_schema.Table.dialect_options`. Pull request courtesy of Ramon Will. Fixes: #4038 Closes: #5536 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5536 Pull-request-sha: f8852cabe15c9a91de85d27980988051f7a1306d Change-Id: I69b60576532af04c725c998e9e8fec6e2040b149
* repair doc warningsMike Bayer2022-08-081-1/+1
| | | | | Change-Id: I446105028539a34da90d6b8ae4812965cc398ee5 (cherry picked from commit c539ee35229b03d61f2a10e9f5ab613201341e19)
* ensure RETURNING renders in stringify w/ no server versionMike Bayer2022-08-031-0/+6
| | | | | | | | | just in my own testing, if I say insert().return_defaults() and stringify, I should see it, so make sure all the dialects default to "insert_returning" etc. , with downgrade on server version check. Change-Id: Id64e78fcb03c48b5dcb0feb21cb9cc495edd15e9
* Update to flake8 5.Federico Caselli2022-07-311-1/+2
| | | | Change-Id: I5a241a70efba68bcea9819ddce6aebc25703e68d
* document create_engine.isolation_level for PGMike Bayer2022-07-131-0/+5
| | | | | Change-Id: I06eaede9e021eb0790929168e9bedb0c8b58140a References: #8252
* Comments on (named) constraintscheremnov2022-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds support for comments on named constraints, including `ForeignKeyConstraint`, `PrimaryKeyConstraint`, `CheckConstraint`, `UniqueConstraint`, solving the [Issue 5667](https://github.com/sqlalchemy/sqlalchemy/issues/5667). Supports only PostgreSQL backend. ### Description Following the example of [Issue 1546](https://github.com/sqlalchemy/sqlalchemy/issues/1546), supports comments on constraints. Specifically, enables comments on _named_ ones — as I get it, PostgreSQL prohibits comments on unnamed constraints. Enables setting the comments for named constraints like this: ``` Table( 'example', metadata, Column('id', Integer), Column('data', sa.String(30)), PrimaryKeyConstraint( "id", name="id_pk", comment="id_pk comment" ), CheckConstraint('id < 100', name="cc1", comment="Id value can't exceed 100"), UniqueConstraint(['data'], name="uc1", comment="Must have unique data field"), ) ``` Provides the DDL representation for constraint comments and routines to create and drop them. Class `.Inspector` reflects constraint comments via methods like `get_check_constraints` . ### 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 - [ ] A short code fix - [x] A new feature implementation - Solves the issue 5667. - The commit message includes `Fixes: 5667`. - Includes tests based on comment reflection. **Have a nice day!** Fixes: #5667 Closes: #7742 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7742 Pull-request-sha: 42a5d3c3e9ccf9a9d5397fd007aeab0854f66130 Change-Id: Ia60f578595afdbd6089541c9a00e37997ef78ad3
* rearchitect reflection for batched performanceFederico Caselli2022-06-181-14/+33
| | | | | | | | | | | | | | | | | | | | | | | Rearchitected the schema reflection API to allow some dialects to make use of high performing batch queries to reflect the schemas of many tables at once using much fewer queries. The new performance features are targeted first at the PostgreSQL and Oracle backends, and may be applied to any dialect that makes use of SELECT queries against system catalog tables to reflect tables (currently this omits the MySQL and SQLite dialects which instead make use of parsing the "CREATE TABLE" statement, however these dialects do not have a pre-existing performance issue with reflection. MS SQL Server is still a TODO). The new API is backwards compatible with the previous system, and should require no changes to third party dialects to retain compatibility; third party dialects can also opt into the new system by implementing batched queries for schema reflection. Along with this change is an updated reflection API that is fully :pep:`484` typed, features many new methods and some changes. Fixes: #4379 Change-Id: I897ec09843543aa7012bcdce758792ed3d415d08
* Merge "migrate labels to new tutorial" into mainmike bayer2022-06-072-2/+2
|\
| * migrate labels to new tutorialMike Bayer2022-06-072-2/+2
| | | | | | | | | | | | | | other org changes and some sections from old tutorial ported to new tutorial. Change-Id: Ic0fba60ec82fff481890887beef9ed0fa271875a
* | Generalize RETURNING and suppor for MariaDB / SQLiteDaniel Black2022-06-021-2/+43
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As almost every dialect supports RETURNING now, RETURNING is also made more of a default assumption. * the default compiler generates a RETURNING clause now when specified; CompileError is no longer raised. * The dialect-level implicit_returning parameter now has no effect. It's not fully clear if there are real world cases relying on the dialect-level parameter, so we will see once 2.0 is released. ORM-level RETURNING can be disabled at the table level, and perhaps "implicit returning" should become an ORM-level option at some point as that's where it applies. * Altered ORM update() / delete() to respect table-level implicit returning for fetch. * Since MariaDB doesnt support UPDATE returning, "full_returning" is now split into insert_returning, update_returning, delete_returning * Crazy new thing. Dialects that have *both* cursor.lastrowid *and* returning. so now we can pick between them for SQLite and mariadb. so, we are trying to keep it on .lastrowid for simple inserts with an autoincrement column, this helps with some edge case test scenarios and i bet .lastrowid is faster anyway. any return_defaults() / multiparams etc then we use returning * SQLite decided they dont want to return rows that match in ON CONFLICT. this is flat out wrong, but for now we need to work with it. Fixes: #6195 Fixes: #7011 Closes: #7047 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7047 Pull-request-sha: d25d5ea3abe094f282c53c7dd87f5f53a9e85248 Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: I9908ce0ff7bdc50bd5b27722081767c31c19a950
* add backend agnostic UUID datatypeMike Bayer2022-06-011-0/+3
| | | | | | | | | | | | | | | | | | | | Added new backend-agnostic :class:`_types.Uuid` datatype generalized from the PostgreSQL dialects to now be a core type, as well as migrated :class:`_types.UUID` from the PostgreSQL dialect. Thanks to Trevor Gross for the help on this. also includes: * corrects some missing behaviors in the suite literal fixtures test where row round trips weren't being correctly asserted. * fixes some of the ISO literal date rendering added in 952383f9ee0 for #5052 to truncate datetime strings for date/time datatypes in the same way that drivers typically do for bound parameters; this was not working fully and wasn't caught by the broken test fixture Fixes: #7212 Change-Id: I981ac6d34d278c18281c144430a528764c241b04
* Include new MySQL error code 4031 for MySQL disconnect checkvalievkarim2022-05-191-0/+1
| | | | | | | | | | | | | | Added disconnect code for MySQL error 4031, introduced in MySQL >= 8.0.24, indicating connection idle timeout exceeded. In particular this repairs an issue where pre-ping could not reconnect on a timed-out connection. Pull request courtesy valievkarim. Fixes: #8036 Closes: #8037 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/8037 Pull-request-sha: 7ab605c2d25c3cd83af41e3250c97c623220cc7a Change-Id: I21249c9d8acb305ac43ce61b90b41daf7fabdfe8
* explicitly fetch inserted pk for values(pkcol=None)Mike Bayer2022-05-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | Altered the compilation mechanics of the :class:`.Insert` construct such that the "autoincrement primary key" column value will be fetched via ``cursor.lastrowid`` or RETURNING even if present in the parameter set or within the :meth:`.Insert.values` method as a plain bound value, for single-row INSERT statements on specific backends that are known to generate autoincrementing values even when explicit NULL is passed. This restores a behavior that was in the 1.3 series for both the use case of separate parameter set as well as :meth:`.Insert.values`. In 1.4, the parameter set behavior unintentionally changed to no longer do this, but the :meth:`.Insert.values` method would still fetch autoincrement values up until 1.4.21 where :ticket:`6770` changed the behavior yet again again unintentionally as this use case was never covered. The behavior is now defined as "working" to suit the case where databases such as SQLite, MySQL and MariaDB will ignore an explicit NULL primary key value and nonetheless invoke an autoincrement generator. Fixes: #7998 Change-Id: I5d4105a14217945f87fbe9a6f2a3c87f6ef20529
* bypass pyodbc default server version / set charsetMike Bayer2022-05-031-0/+6
| | | | | | | | | Further adjustments to the MySQL PyODBC dialect to allow for complete connectivity, which was previously still not working despite fixes in :ticket:`7871`. Fixes: #7966 Change-Id: I549ea9e7b6e722e22d3e25bdb2fe0934603e2454
* inline mypy config; files ignoring type errors for the momentMike Bayer2022-04-2819-0/+38
| | | | | | | | | | | | | | | | | | | to simplify pyproject.toml change the remaining files that aren't going to be typed on this first pass (unless of course someone wants to type some of these) to include # mypy: ignore-errors. for the moment, only a handful of ORM modules are to have more type checking implemented. It's important that ignore-errors is used and not "# type: ignore", as in the latter case, mypy doesn't even read the existing types in the file, which makes it impossible to type any files that refer to those modules at all. to simplify ongoing typing work use inline mypy config for remaining files that are "done" for now, indicating the level of type checking they currently have. Change-Id: I98669c1a305c2f0adba85d10b5425541f3fe9533
* repair fetch_setting call in mysql pyodbc dialectMike Bayer2022-04-261-1/+1
| | | | | | | | | Fixed a regression in the untested MySQL PyODBC dialect caused by the fix for :ticket:`7518` in version 1.4.32 where an argument was being propagated incorrectly upon first connect, leading to a ``TypeError``. Fixes: #7871 Change-Id: I37f8ca8e83cb352ee2a2336b52863858259b1d77
* implement multi-element expression constructsMike Bayer2022-04-131-0/+7
| | | | | | | | | | | | | | | | | | | | | | Improved the construction of SQL binary expressions to allow for very long expressions against the same associative operator without special steps needed in order to avoid high memory use and excess recursion depth. A particular binary operation ``A op B`` can now be joined against another element ``op C`` and the resulting structure will be "flattened" so that the representation as well as SQL compilation does not require recursion. To implement this more cleanly, the biggest change here is that column-oriented lists of things are broken away from ClauseList in a new class ExpressionClauseList, that also forms the basis of BooleanClauseList. ClauseList is still used for the generic "comma-separated list" of things such as Tuple and things like ORDER BY, as well as in some API endpoints. Also adds __slots__ to the TypeEngine-bound Comparator classes. Still can't really do __slots__ on ClauseElement. Fixes: #7744 Change-Id: I81a8ceb6f8f3bb0fe52d58f3cb42e4b6c2bc9018
* implement iso date literals for all backendsMike Bayer2022-04-082-2/+2
| | | | | | | | | | | | Added modified ISO-8601 rendering (i.e. ISO-8601 with the T converted to a space) when using ``literal_binds`` with the SQL compilers provided by the PostgreSQL, MySQL, MariaDB, MSSQL, Oracle dialects. For Oracle, the ISO format is wrapped inside of an appropriate TO_DATE() function call. Previously this rendering was not implemented for dialect-specific compilation. Fixes: #5052 Change-Id: I7af15a51fedf5c5a8e76e645f7c3be997ece35f0
* bump black to 22.3.0Mike Bayer2022-03-281-2/+2
| | | | | | | | | both black and click were released in the past few hours, and black 21.5b1 seems to suddenly be failing on a missing symbol from click. just update to the latest Change-Id: Idf76732479a264f7f2245699a6bdaff018e3a123
* pep 484 for typesMike Bayer2022-03-191-7/+9
| | | | | | | strict types type_api.py, including TypeDecorator, NativeForEmulated, etc. Change-Id: Ib2eba26de0981324a83733954cb7044a29bbd7db
* Merge "Fix repr for MySQL SET, generic Enum" into mainmike bayer2022-03-041-0/+9
|\
| * Fix repr for MySQL SET, generic Enumpetit872022-03-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issues in :class:`_mysql.SET` datatype as well as :class:`.Enum` where the ``__repr__()`` method would not render all optional parameters in the string output, impacting the use of these types in Alembic autogenerate. Pull request for MySQL courtesy Yuki Nishimine. Fixes: #7720 Fixes: #7789 Closes: #7772 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7772 Pull-request-sha: d58845479f497f6b2e12d7df2e9eb2d6ac22109b Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: Idcec23eab4258511d9f32f4e3d78e511ea6021f1
* | pep-484 for engineMike Bayer2022-03-018-8/+8
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All modules in sqlalchemy.engine are strictly typed with the exception of cursor, default, and reflection. cursor and default pass with non-strict typing, reflection is waiting on the multi-reflection refactor. Behavioral changes: * create_connect_args() methods return a tuple of list, dict, rather than a list of list, dict * removed allow_chars parameter from pyodbc connector ._get_server_version_info() method * the parameter list passed to do_executemany is now a list in all cases. previously, this was being run through dialect.execute_sequence_format, which defaults to tuple and was only intended for individual tuple params. * broke up dialect.dbapi into dialect.import_dbapi class method and dialect.dbapi module object. added a deprecation path for legacy dialects. it's not really feasible to type a single attr as a classmethod vs. module type. The "type_compiler" attribute also has this problem with greater ability to work around, left that one for now. * lots of constants changing to be Enum, so that we can type them. for fixed tuple-position constants in cursor.py / compiler.py (which are used to avoid the speed overhead of namedtuple), using Literal[value] which seems to work well * some tightening up in Row regarding __getitem__, which we can do since we are on full 2.0 style result use * altered the set_connection_execution_options and set_engine_execution_options event flows so that the dictionary of options may be mutated within the event hook, where it will then take effect as the actual options used. Previously, changing the dict would be silently ignored which seems counter-intuitive and not very useful. * A lot of DefaultDialect/DefaultExecutionContext methods and attributes, including underscored ones, move to interfaces. This is not fully ideal as it means the Dialect/ExecutionContext interfaces aren't publicly subclassable directly, but their current purpose is more of documentation for dialect authors who should (and certainly are) still be subclassing the DefaultXYZ versions in all cases Overall, Result was the most extremely difficult class hierarchy to type here as this hierarchy passes through largely amorphous "row" datatypes throughout, which can in fact by all kinds of different things, like raw DBAPI rows, or Row objects, or "scalar"/Any, but at the same time these types have meaning so I tried still maintaining some level of semantic markings for these, it highlights how complex Result is now, as it's trying to be extremely efficient and inlined while also being very open-ended and extensible. Change-Id: I98b75c0c09eab5355fc7a33ba41dd9874274f12a
* Implement generic Double and related fixed typeszeeeeeb2022-02-252-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added :class:`.Double`, :class:`.DOUBLE`, :class:`.DOUBLE_PRECISION` datatypes to the base ``sqlalchemy.`` module namespace, for explicit use of double/double precision as well as generic "double" datatypes. Use :class:`.Double` for generic support that will resolve to DOUBLE/DOUBLE PRECISION/FLOAT as needed for different backends. Implemented DDL and reflection support for ``FLOAT`` datatypes which include an explicit "binary_precision" value. Using the Oracle-specific :class:`_oracle.FLOAT` datatype, the new parameter :paramref:`_oracle.FLOAT.binary_precision` may be specified which will render Oracle's precision for floating point types directly. This value is interpreted during reflection. Upon reflecting back a ``FLOAT`` datatype, the datatype returned is one of :class:`_types.DOUBLE_PRECISION` for a ``FLOAT`` for a precision of 126 (this is also Oracle's default precision for ``FLOAT``), :class:`_types.REAL` for a precision of 63, and :class:`_oracle.FLOAT` for a custom precision, as per Oracle documentation. As part of this change, the generic :paramref:`_sqltypes.Float.precision` value is explicitly rejected when generating DDL for Oracle, as this precision cannot be accurately converted to "binary precision"; instead, an error message encourages the use of :meth:`_sqltypes.TypeEngine.with_variant` so that Oracle's specific form of precision may be chosen exactly. This is a backwards-incompatible change in behavior, as the previous "precision" value was silently ignored for Oracle. Fixes: #5465 Closes: #7674 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/7674 Pull-request-sha: 5c68419e5aee2e27bf21a8ac9eb5950d196c77e5 Change-Id: I831f4af3ee3b23fde02e8f6393c83e23dd7cd34d
View Lorry Controller Status