summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/testing
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge "Modernize tests - select(whereclause)"mike bayer2021-07-122-9/+2
|\
| * Modernize tests - select(whereclause)Gord Thompson2021-07-042-9/+2
| | | | | | | | Change-Id: I306cfbea9920b35100e3087dcc21d7ffa6c39c55
* | Replace all http:// links to https://Federico Caselli2021-07-0417-17/+17
|/ | | | | | Also replace http://pypi.python.org/pypi with https://pypi.org/project Change-Id: I84b5005c39969a82140706472989f2a30b0c7685
* Modernize testsGord Thompson2021-07-031-1/+0
| | | | | | Eliminate engine.execute() and engine.scalar() Change-Id: I99f76d0e615ddebab2da4fd07a40a0a2796995c7
* Modernize tests - Connection.connectGord Thompson2021-06-261-1/+0
| | | | Change-Id: I61639dc2d7e7bcae6c53e2a15680b11fce3efa5d
* turn pg provision error into a warningMike Bayer2021-06-262-0/+11
| | | | | | | | | | | | | We haven't had any real cases of the PG "cant drop tables" condition since this error was first introduced; instead we seem to get it for a non-critical query during pool reconnect tests, and I have not been able to isolate what is causing it. Therefore turn the error into a new class of warning that can emit within the test suite without failing the test, so that if we do get a real PG drop timeout, the warning will be there to show us what the query was in which it was stuck. Change-Id: I1a9b3c4f7a25b7b9c1af722a721fc44ad5575b0f
* init extra_criteria_entities in fromstatement w/ DMLMike Bayer2021-06-071-4/+4
| | | | | | | | | | | | Fixed issue in experimental "select ORM objects from INSERT/UPDATE" use case where an error was raised if the statement were against a single-table-inheritance subclass. Additionally makes some adjustments in the SQL assertion fixture to test a FromStatement w/ DML. Fixes: #6591 Change-Id: I53a627ab18a01dc6d9b5037e28312a1177891327
* delete exception traceback in _expect_raisesMike Bayer2021-06-021-0/+7
| | | | | | | | | | a new segfault is observed in python 3.10.0b2 in conjunction with asyncio and possibly greenlet. Ensuring the traceback object is deleted from scope here, which is a good idea anyway, apparently seems to resolve the issue. Change-Id: Ia83bafb088ef19853044f1d436db259cbfd1e5f4 References: https://github.com/python-greenlet/greenlet/issues/242
* temporarily disable test_no_attach_to_event_loopMike Bayer2021-06-021-2/+10
| | | | | | | | | | | | | | this test currently causes the test suite to hang; it previously was not actually running the worker thread as the testing_engine() fixture was rejecting the "transfer_staticpool" keyword argument. as we seem to have a greenlet-related segfault in 3.10.0b2 I am going to have to get the greenlet devs to run the test suite so i want to get anything not totally smooth out of it for the moment. Change-Id: Ib453d0bc23ca013598bc80ff29e5da496771d5b1
* Remove pytest warning filterFederico Caselli2021-05-281-6/+0
| | | | Change-Id: Ie18b66e4a8d59be12ee549347bd508036282c1c9
* get tests to pass on python 3.10Mike Bayer2021-05-271-2/+11
| | | | | | | | | | | | | | Resolved various deprecation warnings which were appearing as of Python version 3.10.0b1. block aiomysql on python 3.10 as they are using the "loop" argument that's removed sqlcipher-binary has no builds on 3.10, block it for 3.10 Fixes: #6540 Fixes: #6543 Change-Id: Iec1e3881fb289878881ae043b1a18c3ecdf5f077
* Provide primary key values for data in tests that aren't about primary keys.Jim Fulton2021-05-243-17/+33
| | | | | | | | | | | | | | | (message written by Mike) some backends such as BigQuery have no autoincrement mechanism at all. while we would like to pursue a strategy where provisioning.py could provide for an in-Python sequence generator, at least remove the need for autoincrement in suite tests that don't need it. Fixes: #6469 Closes: #6504 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/6504 Pull-request-sha: c075014ef7de33e6eb3f389d24251ba184655e0b Change-Id: I98e237a38417b68c87d0201717205d7655b1f44e
* Merge "Remove pep484 type comments from the code"mike bayer2021-05-182-17/+2
|\
| * Remove pep484 type comments from the codeFederico Caselli2021-05-162-17/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Current effort is around the stub package, and having typing in two places makes thing worse, since the types here are usually outdated compared to the version in the stubs. Once v2 gets under way we can start consolidating the types here. Fixes: #6461 Change-Id: I7132a444bd7138123074bf5bc664b4bb119a85ce
* | Use type_ when creating literals in _LiteralRoundTripFixtureJim Fulton2021-05-171-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes #6496 by passing the `type_` argument passed to `run` to `literal`. 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. **Have a nice day!** Closes: #6497 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/6497 Pull-request-sha: 5f82408b2c25c7593f7202533dde4e29f045de5d Change-Id: Ieed822c157f91d95fe3a07ea4482a36777539c35
* Update black flak8 and zimportsFederico Caselli2021-05-121-1/+1
| | | | Change-Id: I488c9557eda390e4a88319affd4c8813ee274f80
* Merge "don't cache TypeDecorator by default"mike bayer2021-05-061-0/+2
|\
| * don't cache TypeDecorator by defaultMike Bayer2021-05-061-0/+2
| | | | | | | | | | | | | | | | | | | | The :class:`.TypeDecorator` class will now emit a warning when used in SQL compilation with caching unless the ``.cache_ok`` flag is set to ``True`` or ``False``. ``.cache_ok`` indicates that all the parameters passed to the object are safe to be used as a cache key, ``False`` means they are not. Fixes: #6436 Change-Id: Ib1bb7dc4b124e38521d615c2e2e691e4915594fb
* | Merge "unify transactional context managers"mike bayer2021-05-061-0/+144
|\ \
| * | unify transactional context managersMike Bayer2021-05-051-0/+144
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Applied consistent behavior to the use case of calling ``.commit()`` or ``.rollback()`` inside of an existing ``.begin()`` context manager, with the addition of potentially emitting SQL within the block subsequent to the commit or rollback. This change continues upon the change first added in :ticket:`6155` where the use case of calling "rollback" inside of a ``.begin()`` contextmanager block was proposed: * calling ``.commit()`` or ``.rollback()`` will now be allowed without error or warning within all scopes, including that of legacy and future :class:`_engine.Engine`, ORM :class:`_orm.Session`, asyncio :class:`.AsyncEngine`. Previously, the :class:`_orm.Session` disallowed this. * The remaining scope of the context manager is then closed; when the block ends, a check is emitted to see if the transaction was already ended, and if so the block returns without action. * It will now raise **an error** if subsequent SQL of any kind is emitted within the block, **after** ``.commit()`` or ``.rollback()`` is called. The block should be closed as the state of the executable object would otherwise be undefined in this state. Fixes: #6288 Change-Id: I8b21766ae430f0fa1ac5ef689f4c0fb19fc84336
* | | Merge "Parenthesize for empty not in"mike bayer2021-05-051-0/+20
|\ \ \ | |_|/ |/| |
| * | Parenthesize for empty not inMike Bayer2021-05-051-0/+20
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression caused by the "empty in" change just made in :ticket:`6397` 1.4.12 where the expression needs to be parenthesized for the "not in" use case, otherwise the condition will interfere with the other filtering criteria. also amends StrSQLCompiler to use the newer "empty IN" style for its compilation process. Fixes: #6428 Change-Id: I182a552fc0d3065a9e38c0f4ece2deb143735c36
* | mypy: load extra test files from environment variableMaico Timmerman2021-05-041-0/+9
|/ | | | | | | | | | Add --mypy-extra-test-path parameter to pytest execution to list extra directories to load test files from. This enables the stubs repo to load this plugin and specify it's own test directory to run mypy tests. Supports both single file tests and incremental tests based on patch files. Change-Id: Id6424ff15b2f527183b9713384df3d625a8e6eb8
* Merge "Support stream_results in the pg8000 dialect"mike bayer2021-05-021-0/+2
|\
| * Support stream_results in the pg8000 dialectTony Locke2021-04-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Description This change adds support for stream_results for the pg8000 dialect by adding a server side cursor. The server-side cursor is a wrapper around a standard DBAPI cursor, and uses the SQL-level cursors. This is being discussed in issue https://github.com/sqlalchemy/sqlalchemy/issues/6198 and this pull request is really to give a concrete example of what I was suggesting. ### 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: #6356 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/6356 Pull-request-sha: 071e118a6b09a26c511b39b0d589ebd2de8d508c Change-Id: Id1a865adf0ff64294c71814681f5b4d593939db6
* | Merge "Use non-subquery form for empty IN"mike bayer2021-04-291-52/+135
|\ \ | |/ |/|
| * Use non-subquery form for empty INMike Bayer2021-04-291-52/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revised the "EMPTY IN" expression to no longer rely upon using a subquery, as this was causing some compatibility and performance problems. The new approach for selected databases takes advantage of using a NULL-returning IN expression combined with the usual "1 != 1" or "1 = 1" expression appended by AND or OR. The expression is now the default for all backends other than SQLite, which still had some compatibility issues regarding tuple "IN" for older SQLite versions. Third party dialects can still override how the "empty set" expression renders by implementing a new compiler method ``def visit_empty_set_op_expr(self, type_, expand_op)``, which takes precedence over the existing ``def visit_empty_set_expr(self, element_types)`` which remains in place. Fixes: #6258 Fixes: #6397 Change-Id: I2df09eb00d2ad3b57039ae48128fdf94641b5e59
* | Propertly ignore ``Identity`` in MySQL and MariaDb.Federico Caselli2021-04-282-0/+32
|/ | | | | | | | | | | | | | Ensure that the MySQL and MariaDB dialect ignore the :class:`_sql.Identity` construct while rendering the ``AUTO_INCREMENT`` keyword in a create table. The Oracle and PostgreSQL compiler was updated to not render :class:`_sql.Identity` if the database version does not support it (Oracle < 12 and PostgreSQL < 10). Previously it was rendered regardless of the database version. Fixes: #6338 Change-Id: I2ca0902fdd7b4be4fc1a563cf5585504cbea9360
* Merge "omit text from selected_columns; clear memoizations"mike bayer2021-04-222-0/+14
|\
| * omit text from selected_columns; clear memoizationsMike Bayer2021-04-222-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where usage of the :func:`_sql.text` construct inside the columns clause of a :class:`_sql.Select` construct, which is better handled by using a :func:`_sql.literal_column` construct, would nonetheless prevent constructs like :func:`_sql.union` from working correctly. Other use cases, such as constructing subuqeries, continue to work the same as in prior versions where the :func:`_sql.text` construct is silently omitted from the collection of exported columns. Also repairs similar use within the ORM. This adds a new internal method _all_selected_columns. The existing "selected_columns" collection can't store a TextClause and this never worked, so they are omitted. The TextClause is also not "exported", i.e. available for SELECT from a subquery, as was already the case in 1.3, so the "exported_columns" and "exported_columns_iterator" accessors are where we now omit TextClause. Fixed regression involving legacy methods such as :meth:`_sql.Select.append_column` where internal assertions would fail. Fixes: #6343 Fixes: #6261 Change-Id: I7c2e5b9ae5d94131c77599a020f4310dcf812bcf
* | Ensure sparse backend selection sorts on driver alsoMike Bayer2021-04-221-0/+1
|/ | | | | | | | | | | | | | | | Because we have --dbdriver now, we usually have lots of db drivers queued up which affect the selection of backend tests. the sort in possible_configs_for_cls() is used so that when we are only picking some backends due to the sparse flag, we get the same answer each time otherwise pytest-xdist raises an error if two workers have different tests. adding the sort for driver fixes an issue on jenkins master build where the memusage test run frequently failed due to mismatched test collection. Change-Id: I8584c1a3a4e5b759c0e5a2602a93432d9cc8168d
* Add new "sync once" mode for pool.connectMike Bayer2021-04-211-2/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed critical regression caused by the change in :ticket`5497` where the connection pool "init" phase no longer occurred within mutexed isolation, allowing other threads to proceed with the dialect uninitialized, which could then impact the compilation of SQL statements. This issue is essentially the same regression which was fixed many years ago in :ticket:`2964` in dd32540dabbee0678530fb1b0868d1eb41572dca, which was missed this time as the test suite fo that issue only tested the pool in isolation, and assumed the "first_connect" event would be used by the Engine. However :ticket:`5497` stopped using "first_connect" and no test detected the lack of mutexing, that has been resolved here through the addition of more tests. This fix also identifies what is probably a bug in earlier versions of SQLAlchemy where the "first_connect" handler would be cancelled if the initializer failed; this is evidenced by test_explode_in_initializer which was doing a reconnect due to c.rollback() yet wasn't hanging. We now solve this issue by preventing the manufactured Connection from ever reconnecting inside the first_connect handler. Also remove the "_sqla_unwrap" test attribute; this is almost not used anymore however we can use a more targeted wrapper supplied by the testing.engines.proxying_engine function. See if we can also open up Oracle for "ad hoc engines" tests now that we have better connection management logic. Fixes: #6337 Change-Id: I4a3476625c4606f1a304dbc940d500325e8adc1a
* don't base compilation off the int value of offset/limit part IIMike Bayer2021-04-141-11/+18
| | | | | | | | | | | | | | | | Fixed an additional regression in the same area as that of :ticket:`6184`, where using a value of 0 for OFFSET in conjunction with LIMIT with SQL Server would create a statement using "TOP", as was the behavior in 1.3, however due to caching would then fail to respond accordingly to other values of OFFSET. If the "0" wasn't first, then it would be fine. For the fix, the "TOP" syntax is now only emitted if the OFFSET value is omitted entirely, that is, :meth:`_sql.Select.offset` is not used. Note that this change now requires that if the "with_ties" or "percent" modifiers are used, the statement can't specify an OFFSET of zero, it now needs to be omitted entirely. Fixes: #6265 Change-Id: If30596b8dcd9f2ce4221cd87c5407fa81f5f9a90
* Support DEFAULT VALUES and VALUES(DEFAULT) individuallyMike Bayer2021-04-144-3/+31
| | | | | | | | | | | | | Fixed regression where the introduction of the INSERT syntax "INSERT... VALUES (DEFAULT)" was not supported on some backends that do however support "INSERT..DEFAULT VALUES", including SQLite. The two syntaxes are now each individually supported or non-supported for each dialect, for example MySQL supports "VALUES (DEFAULT)" but not "DEFAULT VALUES". Support for Oracle is still not enabled as there are unresolved issues in using RETURNING at the same time. Fixes: #6254 Change-Id: I47959bc826e3d9d2396ccfa290eb084841b02e77
* Make schema support explicitGord Thompson2021-04-091-1/+2
| | | | | | | | | Add ``supports_schema = True`` to DefaultDialect and modify requirements.py to use that attribute so third-party dialects can explicitly indicate that they do *not* support schemas by specifying ``supports_schema = False`` in their Dialect class. Change-Id: Idffee82f6668a15ac7148f2a407a17de785d1fb7
* Fix LegacyRow/Row index accessMike Bayer2021-04-081-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed up the behavior of the :class:`_result.Row` object when dictionary access is used upon it, meaning converting to a dict via ``dict(row)`` or accessing members using strings or other objects i.e. ``row["some_key"]`` works as it would with a dictionary, rather than raising ``TypeError`` as would be the case with a tuple, whether or not the C extensions are in place. This was originally supposed to emit a 2.0 deprecation warning for the "non-future" case using :class:`_result.LegacyRow`, and was to raise ``TypeError`` for the "future" :class:`_result.Row` class. However, the C version of :class:`_result.Row` was failing to raise this ``TypeError``, and to complicate matters, the :meth:`_orm.Session.execute` method now returns :class:`_result.Row` in all cases to maintain consistency with the ORM result case, so users who didn't have C extensions installed would see different behavior in this one case for existing pre-1.4 style code. Therefore, in order to soften the overall upgrade scheme as most users have not been exposed to the more strict behavior of :class:`_result.Row` up through 1.4.6, :class:`_result.LegacyRow` and :class:`_result.Row` both provide for string-key access as well as support for ``dict(row)``, in all cases emitting the 2.0 deprecation warning when ``SQLALCHEMY_WARN_20`` is enabled. The :class:`_result.Row` object still uses tuple-like behavior for ``__contains__``, which is probably the only noticeable behavioral change compared to :class:`_result.LegacyRow`, other than the removal of dictionary-style methods ``values()`` and ``items()``. Also remove filters for result set warnings. callcounts updated for 2.7/ 3.9, am pushing jenkins to use python 3.9 now Fixes: #6218 Change-Id: Ia69b974f3dbc46943c57423f57ec82323c8ae63b
* Merge "Disallow AliasedReturnsRows from execution"mike bayer2021-04-061-5/+9
|\
| * Disallow AliasedReturnsRows from executionMike Bayer2021-04-051-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Executing a :class:`_sql.Subquery` using :meth:`_engine.Connection.execute` is deprecated and will emit a deprecation warning; this use case was an oversight that should have been removed from 1.4. The operation will now execute the underlying :class:`_sql.Select` object directly for backwards compatibility. Similarly, the :class:`_sql.CTE` class is also not appropriate for execution. In 1.3, attempting to execute a CTE would result in an invalid "blank" SQL statement being executed; since this use case was not working it now raises :class:`_exc.ObjectNotExecutableError`. Previously, 1.4 was attempting to execute the CTE as a statement however it was working only erratically. The change also breaks out StatementRole from ReturnsRowsRole, as these roles should not be in the same lineage (some statements don't return rows, the whole class of ReturnsRows that are from clauses are not statements). Consolidate StatementRole and CoerceTextStatementRole as there's no usage difference between these. Simplify some old tests that were trying to make sure that "execution options" didn't transmit from a cte/subquery out to a select; as cte/subuqery() aren't executable in any case the options are removed. Fixes: #6204 Change-Id: I62613b7ab418afdd22c409eae75659e3f52fb65f
* | uniquify when popping literal_execute_params from param dictMike Bayer2021-04-051-0/+14
|/ | | | | | | | | | | Fixed further issues in the same area as that of :ticket:`6173` released in 1.4.5, where a "postcompile" parameter, again most typically those used for LIMIT/OFFSET rendering in Oracle and SQL Server, would fail to be processed correctly if the same parameter rendered in multiple places in the statement. Fixes: #6202 Change-Id: I95c355aa52a7546fe579ad67f9a8402a213cb79d
* Merge "Fix MSSQL / Oracle limit/offset regressions"mike bayer2021-04-011-70/+198
|\
| * Fix MSSQL / Oracle limit/offset regressionsFederico Caselli2021-03-311-70/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed a regression in MSSQL 2012+ that prevented the order clause to be rendered when ``offset=0`` is used in a subquery. Fixed critical regression where the Oracle compiler would not maintain the correct parameter values in the LIMIT/OFFSET for a select due to a caching issue. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Fixes: #6163 Fixes: #6173 Change-Id: Ieb12354271d09ad935d684ee0db4fa0128837215
* | Merge "Add DeclarativeMeta to globals"mike bayer2021-03-311-0/+12
|\ \ | |/ |/|
| * Add DeclarativeMeta to globalsMike Bayer2021-03-311-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue in mypy plugin where newly added support for :func:`_orm.as_declarative` needed to more fully add the ``DeclarativeMeta`` class to the mypy interpreter's state so that it does not result in a name not found error; additionally improves how global names are setup for the plugin including the ``Mapped`` name. Introduces directory oriented testing as well, where a full set of files will be copied, mypy runs, then zero or more patches are applied and mypy is run again, to fully test incremental behaviors. Fixes: sqlalchemy/sqlalchemy2-stubs/#14 Change-Id: Ide785c07e19ba0694e8cf6f91560094ecb182016
* | Repair exception handling in CursorResultFederico Caselli2021-03-301-0/+2
|/ | | | | Fixes: #6138 Change-Id: I794a3da688fd8577fb06770ef02bf827a5c55397
* Repair pysqlcipher and use sqlcipher3Mike Bayer2021-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The ``pysqlcipher`` dialect now imports the ``sqlcipher3`` module for Python 3 by default. Regressions have been repaired such that the connection routine was not working. To better support the post-connection steps of the pysqlcipher dialect, a new hook Dialect.on_connect_url() is added, which supersedes Dialect.on_connect() and is passed the URL object. The dialect now pulls the passphrase and other cipher args from the URL directly without including them in the "connect" args. This will allow any user-defined extensibility to connecting to work as it would for other dialects. The commit also builds upon the extended routines in sqlite/provisioning.py to better support running tests against multiple simultaneous SQLite database files. Additionally enables backend for test_sqlite which was skipping everything for aiosqlite too, fortunately everything there is passing. Fixes: #5848 Change-Id: I43f53ebc62298a84a4abe149e1eb699a027b7915
* Merge "Add support for aiosqlite"mike bayer2021-03-245-9/+49
|\
| * Add support for aiosqliteFederico Caselli2021-03-245-9/+49
| | | | | | | | | | | | | | | | Added support for the aiosqlite database driver for use with the SQLAlchemy asyncio extension. Fixes: #5920 Change-Id: Id11a320516a44e886a6f518d2866a0f992413e55
* | Remove internal use of string attr in loader optionMike Bayer2021-03-231-3/+14
|/ | | | | | | | | | | | | | | | | | Fixed issue where a "removed in 2.0" warning were generated internally by the relationship loader mechanics. This changeset started the effort of converting all string usage in the test suite, however this is a much longer job as the use of strings in loader options is widespread. In particular I'm not totally comfortable with strings not being accepted in obvious spots like Load(User).load_only("x", "y", "z"), which points to a new string expecting functionality that's not what's there now. However at the moment it seems like we need to continue removing all support for strings and then figure out "immediate strings from an explicit class" later. Fixes: #6115 Change-Id: I6b314d135d2bc049fd66500914b772c1fe60b5b3
* Deannoate functions before matching .__class__Mike Bayer2021-03-191-0/+6
| | | | | | | | | | Fixed regression where the SQL compilation of a :class:`.Function` would not work correctly if the object had been "annotated", which is an internal memoization process used mostly by the ORM. In particular it could affect ORM lazy loads which make greater use of this feature in 1.4. Fixes: #6095 Change-Id: I7a6527df651f440a04d911ba78ee0b0dd4436dcd
* Merge "CAST the elements in ARRAYs when using psycopg2"mike bayer2021-03-164-1/+50
|\
View Lorry Controller Status