summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/orm/query.py
Commit message (Collapse)AuthorAgeFilesLines
...
* warnings removal, merge_resultMike Bayer2021-10-291-0/+7
| | | | | | | | | | | this is the last warning to remove. Also fixes some mistakes I made with the new Base20DeprecationWarning and LegacyAPIWarning classes created, where functions in deprecations.py were still hardcoded to RemovedIn20Warning. Change-Id: I9a6045ac9b813fd2f9668c4bc518c46a7774c6ef
* clarify order_by(None) for Core; improve wordingMike Bayer2021-10-291-3/+11
| | | | | | | the order_by(None) convention was documented for orm.Query but not Core select. Change-Id: I0c1ad76c3eefba1cb54b1649cfd09169c17e2bba
* Merge "deprecation warnings: with_parent, aliased, from_joinpoint" into mainmike bayer2021-10-271-0/+1
|\
| * deprecation warnings: with_parent, aliased, from_joinpointMike Bayer2021-10-271-0/+1
| | | | | | | | | | | | | | | | | | most of the work for aliased / from_joinpoint has been done already as I added all new tests for these and moved most aliased/from_joinpoint to test/orm/test_deprecations.py already Change-Id: Ia23e332dec183de17b2fb9d89d946af8d5e89ae7
* | Merge "Fixes: #4100" into mainmike bayer2021-10-271-0/+9
|\ \ | |/ |/|
| * Fixes: #4100jonathan vanasco2021-10-261-0/+9
| | | | | | | | | | | | | | | | | | | | Add a warning, in two places, stating `with_for_update` will lock joinedload tables, because at least one person did not expect the obvious to happen. Also warn that eager loading techniques may not work with `with_for_update` and combining the two is not officially supported or recommended. Change-Id: Iedd609b56b3144d90a90fc2eea3cf5335a2d178a
* | dont pull filter_by from from_obj, entity is hopefully sufficientMike Bayer2021-10-261-1/+31
|/ | | | | | | | | Fixed 1.4 regression where :meth:`_orm.Query.filter_by` would not function correctly on a :class:`_orm.Query` that was produced from :meth:`_orm.Query.union`, :meth:`_orm.Query.from_self` or similar. Fixes: #7239 Change-Id: I3a0c3fd71180b1bfb6bf855f436a29c729664082
* Implement nesting CTEEric Masseran2021-09-171-2/+2
| | | | | | | | | | | | | | | | | | Added new parameter :meth:`_sql.HasCte.cte.nesting` to the :class:`_sql.CTE` constructor and :meth:`_sql.HasCTE.cte` method, which flags the CTE as one which should remain nested within an enclosing CTE, rather than being moved to the top level of the outermost SELECT. While in the vast majority of cases there is no difference in SQL functionality, users have identified various edge-cases where true nesting of CTE constructs is desirable. Much thanks to Eric Masseran for lots of work on this intricate feature. Fixes: #4123 Closes: #6709 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/6709 Pull-request-sha: 64ab2f6ea269f2dcf37376a13ea38c48c5226fb6 Change-Id: Ic4dc25ab763af96d96632369e01527d48a654149
* remove lambda caching from loader strategiesMike Bayer2021-08-171-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjusted ORM loader internals to no longer use the "lambda caching" system that was added in 1.4, as well as repaired one location that was still using the previous "baked query" system for a query. The lambda caching system remains an effective way to reduce the overhead of building up queries that have relatively fixed usage patterns. In the case of loader strategies, the queries used are responsible for moving through lots of arbitrary options and criteria, which is both generated and sometimes consumed by end-user code, that make the lambda cache concept not any more efficient than not using it, at the cost of more complexity. In particular the problems noted by :ticket:`6881` and :ticket:`6887` are made considerably less complicated by removing this feature internally. Fixed an issue where the :class:`_orm.Bundle` construct would not create proper cache keys, leading to inefficient use of the query cache. This had some impact on the "selectinload" strategy and was identified as part of :ticket:`6889`. Added a Select._create_raw_select() method which essentially performs ``__new__`` and then populates ``__dict__`` directly, with no coercions. This saves most of the overhead time that the lambda caching system otherwise seeks to avoid. Includes removal of bakedquery from mapper->_subclass_load_via_in() which was overlooked from the 1.4 refactor. Fixes: #6079 Fixes: #6889 Change-Id: Ieac2d9d709b71ec4270e5c121fbac6ac870e2bb1
* Apply new uniquing rules for future ORM selectsMike Bayer2021-07-211-1/+3
| | | | | | | | | | | | | | | | | | | | Fixed issue where usage of the :meth:`_result.Result.unique` method with an ORM result that included column expressions with unhashable types, such as ``JSON`` or ``ARRAY`` using non-tuples would silently fall back to using the ``id()`` function, rather than raising an error. This now raises an error when the :meth:`_result.Result.unique` method is used in a 2.0 style ORM query. Additionally, hashability is assumed to be True for result values of unknown type, such as often happens when using SQL functions of unknown return type; if values are truly not hashable then the ``hash()`` itself will raise. For legacy ORM queries, since the legacy :class:`_orm.Query` object uniquifies in all cases, the old rules remain in place, which is to use ``id()`` for result values of unknown type as this legacy uniquing is mostly for the purpose of uniquing ORM entities and not column values. Fixes: #6769 Change-Id: I5747f706f1e97c78867b5cf28c73360497273808
* Replace all http:// links to https://Federico Caselli2021-07-041-2/+2
| | | | | | Also replace http://pypi.python.org/pypi with https://pypi.org/project Change-Id: I84b5005c39969a82140706472989f2a30b0c7685
* clear new Query._memoized_select_entities in _from_selectableMike Bayer2021-06-301-0/+1
| | | | | | | | | | | Fixed regression caused in 1.4.19 due to #6503 and related involving :meth:`_orm.Query.with_entities` where the new structure used would be inappropriately transferred to an enclosing :class:`_orm.Query` when making use of set operations such as :meth:`_orm.Query.union`, causing the JOIN instructions within to be applied to the outside query as well. Fixes: #6698 Change-Id: Ia9f294215ebc01330d142a0a3e5be9d02be9380f
* set _render_for_subquery for legacy set opsMike Bayer2021-06-261-1/+7
| | | | | | | | | | | | | | | Adjusted :meth:`_orm.Query.union` and similar set operations to be correctly compatible with the new capabilities just added in :ticket:`6661`, with SQLAlchemy 1.4.19, such that the SELECT statements rendered as elements of the UNION or other set operation will include directly mapped columns that are mapped as deferred; this both fixes a regression involving unions with multiple levels of nesting that would produce a column mismatch, and also allows the :func:`_orm.undefer` option to be used at the top level of such a :class:`_orm.Query` without having to apply the option to each of the elements within the UNION. Fixes: #6678 Change-Id: Iba97ce7fd8a965499853256fd2eb7f61512db60f
* memoize current options and joins w with_entities/with_only_colsMike Bayer2021-06-171-0/+4
| | | | | | | | | | | | | | | | Fixed further regressions in the same area as that of :ticket:`6052` where loader options as well as invocations of methods like :meth:`_orm.Query.join` would fail if the left side of the statement for which the option/join depends upon were replaced by using the :meth:`_orm.Query.with_entities` method, or when using 2.0 style queries when using the :meth:`_sql.Select.with_only_columns` method. A new set of state has been added to the objects which tracks the "left" entities that the options / join were made against which is memoized when the lead entities are changed. Fixes: #6503 Fixes: #6253 Change-Id: I211b2af98b0b20d1263fb15dc513884dcc5de6a4
* add some cross-linking for orderby/groupby docs + label examplesMike Bayer2021-04-191-2/+18
| | | | | Change-Id: I34d4958ded8ec95e439ee47fdcb600f357cf7ae3 References: #6324
* test fixes from non-gerrit buildsMike Bayer2021-04-151-3/+1
| | | | | | | | | | | | | - Fix savepoint test in test_memusage which hasn't been running, jenkins now has this enabled for more backends - fix SQL Server failure in test_assorted_eager - don't mention "from_self()" in the error message for Query Fixes: #6277 Change-Id: I0b351032604bd19604143f86f5f055eefd4d0c23
* Disable and disallow Result.unique() with yield_perMike Bayer2021-04-061-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed critical regression where the :meth:`_orm.Query.yield_per` method in the ORM would set up the internal :class:`_engine.Result` to yield chunks at a time, however made use of the new :meth:`_engine.Result.unique` method which uniques across the entire result. This would lead to lost rows since the ORM is using ``id(obj)`` as the uniquing function, which leads to repeated identifiers for new objects as already-seen objects are garbage collected. 1.3's behavior here was to "unique" across each chunk, which does not actually produce "uniqued" results when results are yielded in chunks. As the :meth:`_orm.Query.yield_per` method is already explicitly disallowed when joined eager loading is in place, which is the primary rationale for the "uniquing" feature, the "uniquing" feature is now turned off entirely when :meth:`_orm.Query.yield_per` is used. This regression only applies to the legacy :class:`_orm.Query` object; when using :term:`2.0 style` execution, "uniquing" is not automatically applied. To prevent the issue from arising from explicit use of :meth:`_engine.Result.unique`, an error is now raised if rows are fetched from a "uniqued" ORM-level :class:`_engine.Result` if any :ref:`yield per <orm_queryguide_yield_per>` API is also in use, as the purpose of ``yield_per`` is to allow for arbitrarily large numbers of rows, which cannot be uniqued in memory without growing the number of entries to fit the complete result size. Fixes: #6206 Change-Id: I3770d1f2e9be44d82c83ca992afb912dcc17af05
* Merge "Disallow AliasedReturnsRows from execution"mike bayer2021-04-061-2/+0
|\
| * Disallow AliasedReturnsRows from executionMike Bayer2021-04-051-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Detect (Entity, Entity) vs (Entity, onclause) in legacy joinMike Bayer2021-04-051-4/+24
|/ | | | | | | | | Fixed regression where a deprecated form of :meth:`_orm.Query.join` were used, passing a series of entities to join from without any ON clause in a single :meth:`_orm.Query.join` call, would fail to function correctly. Fixes: #6203 Change-Id: I5a6ec80de972af5b2ca9054e6f24a0b8af4a3e13
* warn / document for Query.with_polymorphic() with with_loader_criteria()Mike Bayer2021-03-231-2/+11
| | | | | | | | | These are illustrated as not working in #6111. As this is a highly complex and legacy method, encourage users to migrate off of it before using with_loader_criteria(). Fixes: #6111 Change-Id: I63c8187020c631d83259ea2200b66eabf74a0d0d
* Restore Query.selectableMike Bayer2021-03-181-0/+12
| | | | | Fixes: #6088 Change-Id: Id014fbd081c0659d1939d059779780798cc8c1dd
* Merge "Ensure entity or None returned from _entity_from_pre_ent_zero()"mike bayer2021-03-171-1/+7
|\
| * Ensure entity or None returned from _entity_from_pre_ent_zero()Mike Bayer2021-03-171-1/+7
| | | | | | | | | | | | | | | | | | Fixed regression where the :meth:`_orm.Query.exists` method would fail to create an expression if the entity list of the :class:`_orm.Query` were an arbitrary SQL column expression. Fixes: #6076 Change-Id: I292dd5f527b2cbc1b76ca765b4ea321ef8535709
* | turn off eager configure_mappers() outside of Query, LoadMike Bayer2021-03-161-3/+12
|/ | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where producing a Core expression construct such as :func:`_sql.select` using ORM entities would eagerly configure the mappers, in an effort to maintain compatibility with the :class:`_orm.Query` object which necessarily does this to support many backref-related legacy cases. However, core :func:`_sql.select` constructs are also used in mapper configurations and such, and to that degree this eager configuration is more of an inconvenience, so eager configure has been disabled for the :func:`_sql.select` and other Core constructs in the absence of ORM loading types of functions such as :class:`_orm.Load`. The change maintains the behavior of :class:`_orm.Query` so that backwards compatibility is maintained. However, when using a :func:`_sql.select` in conjunction with ORM entities, a "backref" that isn't explicitly placed on one of the classes until mapper configure time won't be available unless :func:`_orm.configure_mappers` or the newer :func:`_orm.registry.configure` has been called elsewhere. Prefer using :paramref:`_orm.relationship.back_populates` for more explicit relationship configuration which does not have the eager configure requirement. Fixes: #6066 Change-Id: I7a953ddcc189471fbac63c97c51ab8956f64012e
* Move enable_eagerloads(False) out of _from_self() into count()Mike Bayer2021-03-151-2/+1
| | | | | | | | | | | | | | | | | Fixed regression where calling upon :meth:`_orm.Query.count` in conjunction with a loader option such as :func:`_orm.joinedload` would fail to ignore the loader option. This is a behavior that has always been very specific to the :meth:`_orm.Query.count` method; an error is normally raised if a given :class:`_orm.Query` has options that don't apply to what it is returning. Specifically, the call to enable_eagerloads(False) inside of _from_self() is not needed as loader options are now not invoked for subqueries. Instead, set enable_eagerloads(False) in the count() method itself, so that these options won't be considered in this specific case. Fixes: #6052 Change-Id: I0059ed3fb06156ef4116fd015cbef6f89808e8ef
* Ensure all Query statements compile w/ orm, fix test harnessMike Bayer2021-03-051-0/+10
| | | | | | | | | | | | | | | | | Fixed regression where :meth:`_orm.Query.join` would produce no effect if the query itself as well as the join target were against a :class:`_schema.Table` object, rather than a mapped class. This was part of a more systemic issue where the legacy ORM query compiler would not be correctly used from a :class:`_orm.Query` if the statement produced had not ORM entities present within it. Also repair the assert_compile() method, which was using Query._compile_state() which was bypassing the bug. A handful of ORM tests with Query objects and Core-only objects were actually failing if the default compilation path were used. Fixes: #6003 Change-Id: I97478b2d06bf6c01fe1f09ee118e1f2ac4c849bc
* Allow update.returing() to work with from_statement()Mike Bayer2021-02-141-2/+24
| | | | | | | | | | The ORM used in :term:`2.0 style` can now return ORM objects from the rows returned by an UPDATE..RETURNING or INSERT..RETURNING statement, by supplying the construct to :meth:`_sql.Select.from_statement` in an ORM context. Change-Id: I59c9754ff1cb3184580dd5194ecd2971d4e7f8e8 References: #5940
* Apply consistent labeling for all future style ORM queriesMike Bayer2021-02-111-3/+7
| | | | | | | | | | | | | | | | Fixed issue in new 1.4/2.0 style ORM queries where a statement-level label style would not be preserved in the keys used by result rows; this has been applied to all combinations of Core/ORM columns / session vs. connection etc. so that the linkage from statement to result row is the same in all cases. also repairs a cache key bug where query.from_statement() vs. select().from_statement() would not be disambiguated; the compile options were not included in the cache key for FromStatement. Fixes: #5933 Change-Id: I22f6cf0f0b3360e55299cdcb2452cead2b2458ea
* Merge "Fix many spell glitches in docstrings and comments"mike bayer2021-01-261-10/+10
|\
| * Fix many spell glitches in docstrings and commentsLele Gaifax2021-01-241-10/+10
| | | | | | | | | | | | | | | | | | | | These were revealed by running `pylint --disable all --enable spelling --spelling-dict en_US` over all sources. Closes: #5868 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5868 Pull-request-sha: bb249195d92e3b806e81ecf1192d5a1b3cd5db48 Change-Id: I96080ec93a9fbd20ce21e9e16265b3c77f22bb14
* | Replace with_labels() and apply_labels() in ORM/CoreGord Thompson2021-01-261-16/+41
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace :meth:`_orm.Query.with_labels` and :meth:`_sql.GenerativeSelect.apply_labels` with explicit getters and setters ``get_label_style`` and ``set_label_style`` to accommodate the three supported label styles: ``LABEL_STYLE_DISAMBIGUATE_ONLY`` (default), ``LABEL_STYLE_TABLENAME_PLUS_COL``, and ``LABEL_STYLE_NONE``. In addition, for Core and "future style" ORM queries, ``LABEL_STYLE_DISAMBIGUATE_ONLY`` is now the default label style. This style differs from the existing "no labels" style in that labeling is applied in the case of column name conflicts; with ``LABEL_STYLE_NONE``, a duplicate column name is not accessible via name in any case. For legacy ORM queries using :class:`_query.Query`, the table-plus-column names labeling style applied by ``LABEL_STYLE_TABLENAME_PLUS_COL`` continues to be used so that existing test suites and logging facilities see no change in behavior by default, however this style of labeling is no longer required for SQLAlchemy queries to function, as result sets are commonly matched to columns using a positional approach since SQLAlchemy 1.0. Within test suites, all use of apply_labels() / use_labels now uses the new methods. New tests added to test/sql/test_deprecations.py nad test/orm/test_deprecations.py to cover just the old apply_labels() method call. Tests in ORM that made explicit use apply_labels()/ etc. where it isn't needed for the ORM to work correctly use default label style now. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Fixes: #4757 Change-Id: I5fdcd2ed4ae8c7fe62f8be2b6d0e8f66409b6a54
* happy new yearMike Bayer2021-01-041-1/+1
| | | | Change-Id: Ic5bb19ca8be3cb47c95a0d3315d84cb484bac47c
* Fixes for lambda expressions and relationship loadersMike Bayer2020-12-111-2/+0
| | | | | | | | | | | | | | | | | | Fixed bug in lambda SQL feature, used by ORM :meth:`_orm.with_loader_criteria` as well as available generally in the SQL expression language, where assigning a boolean value True/False to a variable would cause the query-time expression calculation to fail, as it would produce a SQL expression not compatible with a bound value. Fixed issue where the :attr:`_orm.ORMExecuteState.is_relationship_load` parameter would not be set correctly for many lazy loads, all selectinloads, etc. The flag is essential in order to test if options should be added to statements or if they would already have been propagated via relationship loads. Fixes: #5763 Fixes: #5764 Change-Id: I66aafbef193f892ff75ede0670698647b7475482
* Fix documentation link in query with_for_updateFederico Caselli2020-12-021-1/+1
| | | | Change-Id: I4e9a97905d42686c911da81a25f023519328a8a3
* tutorial 2.0 WIPreview/mike_bayer/tutorial20Mike Bayer2020-10-311-73/+14
| | | | | | | | | | | | | | Add SelectBase.exists() method as it seems strange this is not available already. The Exists construct itself does not provide full SELECT-building capabilities so it makes sense this should be used more like a scalar_subquery. Make sure stream_results is getting set up when yield_per is used, for 2.0 style statements as well. this was hardcoded inside of Query.yield_per() and is now moved to take place within QueryContext. Change-Id: Icafcd4fd9b708772343d56edf40995c9e8f835d6
* rename "bulk" UPDATE and DELETE to not use the word "bulk"Mike Bayer2020-10-291-11/+13
| | | | | | | | | | | | This term confuses this feature with the lesser used "bulk insert/update" feature, and also "bulk" is not as descriptive here as only a single statement is run; there's not a large set of data passed in. For now call it UPDATE/DELETE with arbitrary WHERE clause, or ORM-enabled UPDATE/DELETE. Change-Id: I317fcda9d73d4c2dd250031a745dd3d72e4f1fc6
* Deprecate strings indicating attribute namesMike Bayer2020-10-131-8/+32
| | | | | | | | | | | | | | | | | | | Using strings to represent relationship names in ORM operations such as :meth:`_orm.Query.join`, as well as strings for all ORM attribute names in loader options like :func:`_orm.selectinload` is deprecated and will be removed in SQLAlchemy 2.0. The class-bound attribute should be passed instead. This provides much better specificity to the given method, allows for modifiers such as ``of_type()``, and reduces internal complexity. Additionally, the ``aliased`` and ``from_joinpoint`` parameters to :meth:`_orm.Query.join` are also deprecated. The :func:`_orm.aliased` construct now provides for a great deal of flexibility and capability and should be used directly. Fixes: #4705 Fixes: #5202 Change-Id: I32f61663d68026154906932913c288f269991adc
* Merge "Fetch first support"mike bayer2020-10-051-0/+6
|\
| * Fetch first supportFederico Caselli2020-10-021-0/+6
| | | | | | | | | | | | | | | | | | Add support to ``FETCH {FIRST | NEXT} [ count ] {ROW | ROWS} {ONLY | WITH TIES}`` in the select for the supported backends, currently PostgreSQL, Oracle and MSSQL. Fixes: #5576 Change-Id: Ibb5871a457c0555f82b37e354e7787d15575f1f7
* | Improve some documentationsFederico Caselli2020-09-291-1/+0
|/ | | | Change-Id: Ibcb0da3166b94aa58fa92d544c3e5cf75844546e
* upgrade to black 20.8b1Mike Bayer2020-09-281-4/+9
| | | | | | | It's better, the majority of these changes look more readable to me. also found some docstrings that had formatting / quoting issues. Change-Id: I582a45fde3a5648b2f36bab96bad56881321899b
* new docs WIPMike Bayer2020-09-241-0/+8
| | | | | | | | | | | | | | | This WIP is part of the final push for 1.4's docs to fully "2.0-ize" what we can, and have it all ready. So far this includes a rewrite of the 2.0 migration, set up for the 1.4 /2.0 docs style, and a total redesign of the index page using a new flex layout in zzzeeksphinx. It also reworks some of the API reference sections to have more subheaders. zzzeeksphinx is also enhanced to provide automatic summaries for all api doc section. Change-Id: I01d360cb9c8749520246b96ee6496143c6037918
* Deprecate negative slice indexesMike Bayer2020-09-221-1/+5
| | | | | | | | | | | | The "slice index" feature used by :class:`_orm.Query` as well as by the dynamic relationship loader will no longer accept negative indexes in SQLAlchemy 2.0. These operations do not work efficiently and load the entire collection in, which is both surprising and undesirable. These will warn in 1.4 unless the :paramref:`_orm.Session.future` flag is set in which case they will raise IndexError. Fixes: #5606 Change-Id: I5f5dcf984a8f41ab3d0e233ef7553e77fd99a771
* Complete deprecation of from_self()Mike Bayer2020-09-181-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For most from_self() tests, move them into test/orm/test_deprecated.py and replace the existing test with one that uses aliased() plus a subquery. This then revealed a few more issues. Related items: * Added slice() method to GenerativeSelect, to match that of orm.Query and to make possible migration of one of the from_self() tests. moved the utility functions used for this from orm/util into sql/util. * repairs a caching issue related to subqueryload where information being derived from the cached path info was mixing up with query information based on the per-query state, specifically an AliasedClass that is per query. * for the above issue, it seemed like path_registry maybe had to change so that it represents AliasedClass objects as their cache key rather than on identity, but it wasn't needed. still seems like it would be more correct. * enhances the error message raised by coercions for a case such as when an AliasedClass holds onto a select() object and not a subquery(); will name the original and resolved object for clarity (although how is AliasedClass able to accept a Select() object in the first place?) * Added _set_propagate_attrs() to Query so that again if it's passed to AliasedClass, it doesn't raise an error during coercion, but again maybe that should also be rejected up front Fixes: #5368 Change-Id: I5912aa611d899acc87a75eb5ee9f95990592f210
* Create a framework to allow all SQLALCHEMY_WARN_20 to passMike Bayer2020-09-161-2/+11
| | | | | | | | | | | | | | | | | | | | | As the test suite has widespread use of many patterns that are deprecated, enable SQLALCHEMY_WARN_20 globally for the test suite but then break the warnings filter out into a whole list of all the individual warnings we are looking for. this way individual changesets can target a specific class of warning, as many of these warnings will indivdidually affect dozens of files and potentially hundreds of lines of code. Many warnings are also resolved here as this patch started out that way. From this point forward there should be changesets that target a subset of the warnings at a time. For expediency, updates some migration 2.0 docs for ORM as well. Change-Id: I98b8defdf7c37b818b3824d02f7668e3f5f31c94
* Deprecate engine-wise ss cursors; repair mariadbconnectorMike Bayer2020-09-131-1/+3
| | | | | | | | | | | | | | | | | | | The server_side_cursors engine-wide feature relies upon regexp parsing of statements a well as general guessing as to when the feature should be used. This is not within the 2.0 way of doing things and should be removed. Additionally, mariadbconnector defaults to unbuffered cursors; add new cursor hooks so that mariadbconnector can specify buffered or unbuffered cursors without too much difficulty. This will also correctly default mariadbconnector to buffered cursors which should repair the segfaults we've been getting. Try to restore the assert_raises that was removed in 5b6dfc0c38bf1f01da4b8 to see if mariadbconnector segfaults are resolved. Change-Id: I77f1c972c742e40694972f578140bb0cac8c39eb
* Add more docs for populate_existing(); link with_for_updateMike Bayer2020-09-101-2/+17
| | | | | | | | | | | | | The populate_existing() method is actually changing to be an execution option, however it has almost no mention in the narrative docs so add docs in terms of the 1.x version first, including that we mention you almost definitely want to use this method if you are also using with_for_update(). Fixes: #5572 Fixes: #4774 Change-Id: Ieca916400622c1ffc1ae81204132a02a0983594c
* Update select usage to use the new 1.4 formatFederico Caselli2020-09-081-2/+2
| | | | | | | | | | | | | | | | This change includes mainly that the bracketed use within select() is moved to positional, and keyword arguments are removed from calls to the select() function. it does not yet fully address other issues such as keyword arguments passed to the table.select(). Additionally, allows False / None to both be considered as "disable" for all of select.correlate(), select.correlate_except(), query.correlate(), which establishes consistency with passing of ``False`` for the legact select(correlate=False) argument. Change-Id: Ie6c6e6abfbd3d75d4c8de504c0cf0159e6999108
* See if the future is hereMike Bayer2020-08-281-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The docs are going to talk a lot about session.execute(select()) for ORM queries, and additionally it's much easier to help users with queries and such if we can use this new syntax. I'm hoping to see how hard it is to get a unified tutorial started that switches to new syntax. Basically, new syntax is much easier to explain and less buggy. But, if we are starting to present new syntax with the explicit goal of being easier to explain for less experienced programmers, the "future" thing is going to just be an impediment to that. See if we can remove "future" from session.execute(), so that ORM-enabled select() statements return ORM results at that level. This does not change the presence of the "future" flag for the Session's construction and for its transactional behaviors. The only perceptible change of the future flag for session.execute() is that session.execute(select()) where the statement has ORM entities in it now returns ORM new style tuples rather than old style tuples. Like mutating a URL, it's hopefully not very common that people are doing this. Change-Id: I0aa10322bb787d554d32772e3bc60548f1bf6206
View Lorry Controller Status