summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/orm/loading.py
Commit message (Collapse)AuthorAgeFilesLines
...
* Improve rendering of core statements w/ ORM elementsMike Bayer2020-05-311-1/+1
| | | | | | | | | | | | | | | | | | | | This patch contains a variety of ORM and expression layer tweaks to support ORM constructs in select() statements, without the 1.3.x requiremnt in Query that a full _compile_context() + new select() is needed in order to get a working statement object. Includes such tweaks as the ability to implement aliased class of an aliased class, as we are looking to fully support ACs against subqueries, as well as the ability to access anonymously-labeled ColumnProperty expressions within subqueries by naming the ".key" of the label after the property key. Some tuning to query.join() as well as ORMJoin internals to allow things to work more smoothly. Change-Id: Id810f485c5f7ed971529489b84694e02a3356d6d
* Remove loader option cycleMike Bayer2020-05-291-4/+0
| | | | | | | | removed a reference cycle set up by loader options due to the attribute dictionary containing Load objects that reference that dictionary. Change-Id: Ie3159a084f819ae44ca4992b0dbe094fb69b2fa7
* callcount reductions and refinement for cached queriesMike Bayer2020-05-281-73/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit includes that we've removed the "_orm_query" attribute from compile state as well as query context. The attribute created reference cycles and also added method call overhead. As part of this change, the interface for ORMExecuteState changes a bit, as well as the interface for the horizontal sharding extension which now deprecates the "query_chooser" callable in favor of "execute_chooser", which receives the contextual object. This will also work more nicely when we implement the new execution path for bulk updates and deletes. Pre-merge execution options for statement, connection, arguments all up front in Connection. that way they can be passed to the before_execute / after_execute events, and the ExecutionContext doesn't have to merge as second time. Core execute is pretty close to 1.3 now. baked wasn't using the new one()/first()/one_or_none() methods, fixed that. Convert non-buffered cursor strategy to be a stateless singleton. inline all the paths by which the strategy gets chosen, oracle and SQL Server dialects make use of the already-invoked post_exec() hook to establish the alternate strategies, and this is actually much nicer than it was before. Add caching to mapper instance processor for getters. Identified a reference cycle per query that was showing up as a lot of gc cleanup, fixed that. After all that, performance not budging much. Even test_baked_query now runs with significantly fewer function calls than 1.3, still 40% slower. Basically something about the new patterns just makes this slower and while I've walked a whole bunch of them back, it hardly makes a dent. that said, the performance issues are relatively small, in the 20-40% time increase range, and the new caching feature does provide for regular ORM and Core queries that are cached, and they are faster than non-cached. Change-Id: I7b0b0d8ca550c05f79e82f75cd8eff0bbfade053
* Revert 903b18828461bb8cb8dca4acc56809b3df2b14d5Mike Bayer2020-05-251-80/+44
| | | | | | This was accidentally pushed just now. Change-Id: I4da4151c4a81e5cf72146f8dcab3537301ccaae9
* Small callcount reductions and refinement for cached queriesMike Bayer2020-05-251-44/+80
| | | | | | | | | | | | | | | baked wasn't using the new one()/first()/one_or_none() methods, fixed that. loading._instance_processor() can skip setting up the quick populators every time because it can cache the getters. Callcounts have gone below what 1.3 does for the test_baked_query performance suite, however runtime for continued inexplicable reasons has not :(. still suspecting the result tuples but this seems so hard to believe. Change-Id: Ifbca04834d27350e0fa82cb8512e66112abc8729
* Convert execution to move through SessionMike Bayer2020-05-251-40/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch replaces the ORM execution flow with a single pathway through Session.execute() for all queries, including Core and ORM. Currently included is full support for ORM Query, Query.from_statement(), select(), as well as the baked query and horizontal shard systems. Initial changes have also been made to the dogpile caching example, which like baked query makes use of a new ORM-specific execution hook that replaces the use of both QueryEvents.before_compile() as well as Query._execute_and_instances() as the central ORM interception hooks. select() and Query() constructs alike can be passed to Session.execute() where they will return ORM results in a Results object. This API is currently used internally by Query. Full support for Session.execute()->results to behave in a fully 2.0 fashion will be in later changesets. bulk update/delete with ORM support will also be delivered via the update() and delete() constructs, however these have not yet been adapted to the new system and may follow in a subsequent update. Performance is also beginning to lag as of this commit and some previous ones. It is hoped that a few central functions such as the coercions functions can be rewritten in C to re-gain performance. Additionally, query caching is now available and some subsequent patches will attempt to cache more of the per-execution work from the ORM layer, e.g. column getters and adapters. This patch also contains initial "turn on" of the caching system enginewide via the query_cache_size parameter to create_engine(). Still defaulting at zero for "no caching". The caching system still needs adjustments in order to gain adequate performance. Change-Id: I047a7ebb26aa85dc01f6789fac2bff561dcd555d
* Unify Query and select() , move all processing to compile phaseMike Bayer2020-05-241-48/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | Convert Query to do virtually all compile state computation in the _compile_context() phase, and organize it all such that a plain select() construct may also be used as the source of information in order to generate ORM query state. This makes it such that Query is not needed except for its additional methods like from_self() which are all to be deprecated. The construction of ORM state will occur beyond the caching boundary when the new execution model is integrated. future select() gains a working join() and filter_by() method. as we continue to rebase and merge each commit in the steps, callcounts continue to bump around. will have to look at the final result when it's all in. References: #5159 References: #4705 References: #4639 References: #4871 References: #5010 Change-Id: I19e05b3424b07114cce6c439b05198ac47f7ac10
* Performance fixes for new result setMike Bayer2020-05-211-4/+12
| | | | | | | | | | | A few small mistakes led to huge callcounts. Additionally, the warn-on-get behavior which is attempting to warn for deprecated access in SQLAlchemy 2.0 is very expensive; it's not clear if its feasible to have this warning or to somehow alter how it works. Fixes: #5340 Change-Id: I73bdd2d7b6f1b25cc0222accabd585cf761a5af4
* Integrate new Result into ORM queryMike Bayer2020-05-021-38/+62
| | | | | | | | | | | | | | | | | | | | | | | | The next step in the 2.0 ORM changes is to have the ORM integrate with the new Result object fully. this patch uses Result to represent ORM objects rather than lists. public API to get at this Result is not added yet. dogpile.cache and horizontal sharding recipe/extensions have small adjustments to accommodate this change. Callcounts have fluctuated, some slightly better and some slightly worse. A few have gone up by a bit, however as the codebase is still in flux it is anticipated there will be some performance gains later on as ORM fetching is refined to no longer need to accommodate for extensive aliasing. The addition of caching will then change the entire story. References: #5087 References: #4395 Change-Id: If1a23824ffb77d8d58cf2338cf35dd6b5963b17f
* Propose Result as immediate replacement for ResultProxyMike Bayer2020-05-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As progress is made on the _future.Result, including breaking it out such that DBAPI behaviors are local to specific implementations, it becomes apparent that the Result object is a functional superset of ResultProxy and that basic operations like fetchone(), fetchall(), and fetchmany() behave pretty much exactly the same way on the new object. Reorganize things so that ResultProxy is now referred to as LegacyCursorResult, which subclasses CursorResult that represents the DBAPI-cursor version of Result, making use of a multiple inheritance pattern so that the functionality of Result is also available in non-DBAPI contexts, as will be necessary for some ORM patterns. Additionally propose the composition system for Result that will form the basis for ORM-alternative result systems such as horizontal sharding and dogpile cache. As ORM results will soon be coming directly from instances of Result, these extensions will instead build their own ResultFetchStrategies that perform the special steps to create composed or cached result sets. Also considering at the moment not emitting deprecation warnings for fetchXYZ() methods; the immediate issue is Keystone tests are calling upon it, but as the implementations here are proving to be not in any kind of conflict with how Result works, there's not too much issue leaving them around and deprecating at some later point. References: #5087 References: #4395 Fixes: #4959 Change-Id: I8091919d45421e3f53029b8660427f844fee0228
* Run search and replace of symbolic module namesMike Bayer2020-04-141-1/+1
| | | | | | | | Replaces a wide array of Sphinx-relative doc references with an abbreviated absolute form now supported by zzzeeksphinx. Change-Id: I94bffcc3f37885ffdde6238767224296339698a2
* Run autoflush for column attribute load operationsMike Bayer2020-04-031-2/+14
| | | | | | | | | | | | | | | | | The "autoflush" behavior of :class:`.Query` will now trigger for nearly all ORM level attribute load operations, including when a deferred column is loaded as well as when an expired column is loaded. Previously, autoflush on load of expired or unloaded attributes was limited to relationship-bound attributes only. However, this led to the issue where column-based attributes that also depended on other rows, or even other columns in the same row, in order to express the correct value, would show an effectively stale value when accessed as there could be pending changes in the session left to be flushed. Autoflush is now disabled only in some cases where attributes are being unexpired in the context of a history operation. Fixes: #5226 Change-Id: Ibd965b30918cd273ae020411a704bf2bb1891f59
* Test instance for matching class hierarchy on get_from_identityMike Bayer2020-03-221-1/+4
| | | | | | | | | | | Fixed issue where a lazyload that uses session-local "get" against a target many-to-one relationship where an object with the correct primary key is present, however it's an instance of a sibling class, does not correctly return None as is the case when the lazy loader actually emits a load for that row. Fixes: #5210 Change-Id: I89f9946cfeba61d89a272435f76a5a082b1da30c
* Simplified module pre-loading strategy and made it linter friendlyFederico Caselli2020-03-071-2/+3
| | | | | | | | | | | | | | | | | Introduced a modules registry to register modules that should be lazily loaded in the package init. This ensures that they are in the system module cache, avoiding potential thread safety issues as when importing them directly in the function that uses them. The module registry is used to obtain these modules directly, ensuring that the all the lazily loaded modules are resolved at the proper time This replaces dependency_for decorator and the dependencies decorator logic, removing the need to pass the resolved modules as arguments of the decodated functions and removes possible errors caused by linters. Fixes: #4689 Fixes: #4656 Change-Id: I2e291eba4297867fc0ddb5d875b9f7af34751d01
* Ensure all nested exception throws have a causeMike Bayer2020-03-021-3/+3
| | | | | | | | | | | | | | | Applied an explicit "cause" to most if not all internally raised exceptions that are raised from within an internal exception catch, to avoid misleading stacktraces that suggest an error within the handling of an exception. While it would be preferable to suppress the internally caught exception in the way that the ``__suppress_context__`` attribute would, there does not as yet seem to be a way to do this without suppressing an enclosing user constructed context, so for now it exposes the internally caught exception as the cause so that full information about the context of the error is maintained. Fixes: #4849 Change-Id: I55a86b29023675d9e5e49bc7edc5a2dc0bcd4751
* Result initial introductionMike Bayer2020-02-211-22/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This builds on cc718cccc0bf8a01abdf4068c7ea4f3 which moved RowProxy to Row, allowing Row to be more like a named tuple. - KeyedTuple in ORM is replaced with Row - ResultSetMetaData broken out into "simple" and "cursor" versions for ORM and Core, as well as LegacyCursor version. - Row now has _mapping attribute that supplies full mapping behavior. Row and SimpleRow both have named tuple behavior otherwise. LegacyRow has some mapping features on the tuple which emit deprecation warnings (e.g. keys(), values(), etc). the biggest change for mapping->tuple is the behavior of __contains__ which moves from testing of "key in row" to "value in row". - ResultProxy breaks into ResultProxy and FutureResult (interim), the latter has the newer APIs. Made available to dialects using execution options. - internal reflection methods and most tests move off of implicit Row mapping behavior and move to row._mapping, result.mappings() method using future result - a new strategy system for cursor handling replaces the various subclasses of RowProxy - some execution context adjustments. We will leave EC in but refined things like get_result_proxy() and out parameter handling. Dialects for 1.4 will need to adjust from get_result_proxy() to get_result_cursor_strategy(), if they are using this method - out parameter handling now accommodated by get_out_parameter_values() EC method. Oracle changes for this. external dialect for DB2 for example will also need to adjust for this. - deprecate case_insensitive flag for engine / result, this feature is not used mapping-methods on Row are deprecated, and replaced with Row._mapping.<meth>, including: row.keys() -> use row._mapping.keys() row.items() -> use row._mapping.items() row.values() -> use row._mapping.values() key in row -> use key in row._mapping int in row -> use int < len(row) Fixes: #4710 Fixes: #4878 Change-Id: Ieb9085e9bcff564359095b754da9ae0af55679f0
* Merge "Warn for runid changing in load events; add restore_load_context flag"mike bayer2020-01-311-1/+29
|\
| * Warn for runid changing in load events; add restore_load_context flagMike Bayer2020-01-311-1/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added a new flag :paramref:`.InstanceEvents.restore_load_context` and :paramref:`.SessionEvents.restore_load_context` which apply to the :meth:`.InstanceEvents.load`, :meth:`.InstanceEvents.refresh`, and :meth:`.SessionEvents.loaded_as_persistent` events, which when set will restore the "load context" of the object after the event hook has been called. This ensures that the object remains within the "loader context" of the load operation that is already ongoing, rather than the object being transferred to a new load context due to refresh operations which may have occurred in the event. A warning is now emitted when this condition occurs, which recommends use of the flag to resolve this case. The flag is "opt-in" so that there is no risk introduced to existing applications. The change additionally adds support for the ``raw=True`` flag to session lifecycle events. Fixes: #5129 Change-Id: I2912f48ac8c5636297d63ed383454930e8e9a6a3
* | Raise for unexpected polymorphic identityMike Bayer2020-01-291-7/+33
|/ | | | | | | | | | | | | | | | | A query that is against an mapped inheritance subclass which also uses :meth:`.Query.select_entity_from` or a similar technique in order to provide an existing subquery to SELECT from, will now raise an error if the given subquery returns entities that do not correspond to the given subclass, that is, they are sibling or superclasses in the same hierarchy. Previously, these would be returned without error. Additionally, if the inheritance mapping is a single-inheritance mapping, the given subquery must apply the appropriate filtering against the polymorphic discriminator column in order to avoid this error; previously, the :class:`.Query` would add this criteria to the outside query however this interferes with some kinds of query that return other kinds of entities as well. Fixes: #5122 Change-Id: I60cf8c1300d5bb279ad99f0f01fefe7e008a159b
* happy new yearMike Bayer2020-01-011-1/+1
| | | | Change-Id: I08440dc25e40ea1ccea1778f6ee9e28a00808235
* Correctly interpret None passed to query.get(); warn for empty PK valueslizraeli2019-10-281-0/+6
| | | | | | | | | | | | | | | | | A warning is emitted if a primary key value is passed to :meth:`.Query.get` that consists of None for all primary key column positions. Previously, passing a single None outside of a tuple would raise a ``TypeError`` and passing a composite None (tuple of None values) would silently pass through. The fix now coerces the single None into a tuple where it is handled consistently with the other None conditions. Thanks to Lev Izraelit for the help with this. Fixes #4915 Closes: #4917 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4917 Pull-request-sha: b388343c7cabeecf8c779689b78e638c23f9af40 Change-Id: Ibc6c27ccf50dfd4adbf15b6dbd393115c30d44fb
* Add public accessor `is_single_entity` to QueryPatrick Hayes2019-10-271-5/+1
| | | | | | | | | | | | | | | | | Added accessor :attr:`.Query.is_single_entity` to :class:`.Query`, which will indicate if the results returned by this :class:`.Query` will be a list of ORM entities, or a tuple of entities or column expressions. SQLAlchemy hopes to improve upon the behavior of single entity / tuples in future releases such that the behavior would be explicit up front, however this attribute should be helpful with the current behavior. Pull request courtesy Patrick Hayes. Fixes: #4934 Closes: #4935 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4935 Pull-request-sha: 98f72b40a896761a65b048cc3722ff2dac4cf2b1 Change-Id: If5db5db3ea46a93406d76ef90b5b588149ba2986
* Implement raiseload for deferred columnsMike Bayer2019-10-161-0/+3
| | | | | | | | | | | | | | | | | | | | | Added "raiseload" feature for ORM mapped columns. As part of this change, the behavior of "deferred" is now more strict; an attribute that is set up as "deferred" at the mapper level no longer participates in an "unexpire" operation; that is, when an unexpire loads all the expired columns of an object which are not themselves in a deferred group, those which are mapper-level deferred will never be loaded. Deferral options set at query time should always be reset by an expiration operation. Renames deferred_scalar_loader to expired_attribute_loader Unfortunately we can't have raiseload() do this because it would break existing wildcard behavior. Fixes: #4826 Change-Id: I30d9a30236e0b69134e4094fb7c1ad2267f089d1
* Merge "Run row value processors up front"mike bayer2019-10-011-11/+10
|\
| * Run row value processors up frontMike Bayer2019-10-011-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | as part of a larger series of changes to generalize row-tuples, RowProxy becomes plain Row and is no longer a "proxy"; the DBAPI row is now copied directly into the Row when constructed, result handling occurs at once. Subsequent changes will break out Row into a new version that behaves fully a tuple. Change-Id: I2ffa156afce5d21c38f28e54c3a531f361345dd5
* | Cancel polymorphic loading in optimized getMike Bayer2019-10-011-3/+4
|/ | | | | | | | | | | | | Since optimized_get for inheriting mappers writes a simple SELECT, we need to cancel out any with_polymorphic selectables that interfere with simple column lookup. While adaptation is another option, just removing the with_polymorphic is much simpler. The issue is not noticeable unless the ResultProxy is not allowing "key fallback" column lookups, which will be the case when this behavior is deprecated. Fixes: #4718 Change-Id: I8fa2f5c0434b6a681813a92ac71fe12712f5d634
* Raise for NULL discriminator and pk is presentMike Bayer2019-09-031-1/+21
| | | | | | | | | An exception is now raised if the ORM loads a row for a polymorphic instance that has a primary key but the discriminator column is NULL, as discriminator columns should not be null. Fixes: #4836 Change-Id: Ice1a853a7dd7687c58079b9933f145b90d314236
* Run eager loaders on unexpireMike Bayer2019-08-231-0/+4
| | | | | | | | | | | | Eager loaders, such as joined loading, SELECT IN loading, etc., when configured on a mapper or via query options will now be invoked during the refresh on an expired object; in the case of selectinload and subqueryload, since the additional load is for a single object only, the "immediateload" scheme is used in these cases which resembles the single-parent query emitted by lazy loading. Change-Id: I7ca2c77bff58dc21015d60093a88c387937376b2 Fixes: #1763
* happy new yearMike Bayer2019-01-111-1/+1
| | | | Change-Id: I6a71f4924d046cf306961c58dffccf21e9c03911
* Post black reformattingMike Bayer2019-01-061-8/+11
| | | | | | | | | | | | | Applied on top of a pure run of black -l 79 in I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9, this set of changes resolves all remaining flake8 conditions for those codes we have enabled in setup.cfg. Included are resolutions for all remaining flake8 issues including shadowed builtins, long lines, import order, unused imports, duplicate imports, and docstring issues. Change-Id: I4f72d3ba1380dd601610ff80b8fb06a2aff8b0fe
* Run black -l 79 against all source filesMike Bayer2019-01-061-140/+241
| | | | | | | | | | | | | | This is a straight reformat run using black as is, with no edits applied at all. The black run will format code consistently, however in some cases that are prevalent in SQLAlchemy code it produces too-long lines. The too-long lines will be resolved in the following commit that will resolve all remaining flake8 issues including shadowed builtins, long lines, import order, unused imports, duplicate imports, and docstring issues. Change-Id: I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9
* Ensure BakedQuery is cloned before we add options to itMike Bayer2018-06-261-3/+3
| | | | | | | | | | Fixed bug in new polymorphic selectin loading where the BakedQuery used internally would be mutated by the given loader options, which would both inappropriately mutate the subclass query as well as carry over the effect to subsequent queries. Change-Id: Iaceecb50557f78484d09e55b3029a0483dfe873f Fixes: #4286
* Use identity_token for refresh(), unexpire, undeferMike Bayer2018-05-031-4/+7
| | | | | | | | | | | | The horizontal sharding extension now makes use of the identity token added to ORM identity keys as part of :ticket:`4137`, when an object refresh or column-based deferred load or unexpiration operation occurs. Since we know the "shard" that the object originated from, we make use of this value when refreshing, thereby avoiding queries against other shards that don't match this object's identity in any case. Change-Id: Ib91637a65d94ace7405998b8410d62944a83f2eb Fixes: #4247
* Refactor "get" to allow for pluggable identity token schemesMike Bayer2018-04-201-4/+19
| | | | | | | | | | | | | | | Fixed regression in 1.2 within sharded query feature where the new "identity_token" element was not being correctly considered within the scope of a lazy load operation, when searching the identity map for a related many-to-one element. The new behavior will allow for making use of the "id_chooser" in order to determine the best identity key to retrieve from the identity map. In order to achieve this, some refactoring of 1.2's "identity_token" approach has made some slight changes to the implementation of ``ShardedQuery`` which should be noted for other derivations of this class. Change-Id: I04fa60535deec2d0cdec89f602935dfebeb9eb9d Fixes: #4228
* Add Query.enable_single_entity()Eric Atkin2018-03-051-1/+2
| | | | | | | | | | Added new feature :meth:`.Query.only_return_tuples`. Causes the :class:`.Query` object to return keyed tuple objects unconditionally even if the query is against a single entity. Pull request courtesy Eric Atkin. Change-Id: Ib0b7f5f78431aa68082e5b200ed577daa4222336 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/425
* Ensure we have states to load when doing poly post loadMike Bayer2018-02-231-2/+2
| | | | | | | | | | Fixed bug in new "polymorphic selectin" loading when a selection of polymorphic objects were to be partially loaded from a relationship lazy loader, leading to an "empty IN" condition within the load that raises an error for the "inline" form of "IN". Change-Id: I721cf5fdf0b9fd2289067d5d2c6bc87fb2436f07 Fixes: #4199
* happy new yearMike Bayer2018-01-121-1/+1
| | | | Change-Id: I3ef36bfd0cb0ba62b3123c8cf92370a43156cf8f
* Limit select in loading for correct typesMike Bayer2018-01-121-7/+17
| | | | | | | | | | | | | | | Fixed bug in new "selectin" relationship loader where the loader could try to load a non-existent relationship when loading a collection of polymorphic objects, where only some of the mappers include that relationship, typically when :meth:`.PropComparator.of_type` is being used. This generalizes the mapper limiting that was present in _load_subclass_via_in() to be part of the PostLoad object itself, and is used by both polymorphic selectin loading and relationship selectin loading. Change-Id: I31416550e27bc8374b673860f57d9dcf96abe87d Fixes: #4156
* Add an identity_token to the identity keyMike Bayer2017-12-221-1/+4
| | | | | | | | | For the purposes of assisting with sharded setups, add a new member to the identity key that can be customized. this allows sharding across databases where the primary key space is shared. Change-Id: Iae3909f5d4c501b62c10d0371fbceb01abda51db Fixes: #4137
* Filter attributes we don't map during a load_scalar_attributesMike Bayer2017-10-281-0/+9
| | | | | | | | | | | | | | Fixed bug where a descriptor that is elsewhere a mapped column or relationship within a hierarchy based on :class:`.AbstractConcreteBase` would be referred towards during a refresh operation, causing an error as the attribute is not mapped as a mapper property. A similar issue can arise for other attributes like the "type" column added by :class:`.AbstractConcreteBase` if the class fails to include "concrete=True" in its mapper, however the check here should also prevent that scenario from causing a problem. Change-Id: I407b07a3a3e2c374da19fc86ed44b987d595dcfa Fixes: #4124
* Ensure col is not None when retrieving quick populatorsMike Bayer2017-08-231-2/+17
| | | | | | | | | | | | | | | | Fixed bug where an :func:`.undefer_group` option would not be recognized if it extended from a relationship that was loading using joined eager loading. In particular we need to double check the column both in terms of the given "adapter" as well as without applying the "adapter" when searching for the column in the result. As we now avoid redoing the row processor step we also improve on callcounts in joined eager loading. Change-Id: I0f48766f12f7299f4626ff41a00bf1f5bfca5f3b Fixes: #4048
* Enable multi-level selectin polymorphic loadingMike Bayer2017-08-071-9/+18
| | | | | Change-Id: Icc742bbeecdb7448ce84caccd63e086af16e81c1 Fixes: #4026
* selectin polymorphic loadingMike Bayer2017-06-051-0/+53
| | | | | | | | | | | | | Added a new style of mapper-level inheritance loading "polymorphic selectin". This style of loading emits queries for each subclass in an inheritance hierarchy subsequent to the load of the base object type, using IN to specify the desired primary key values. Fixes: #3948 Change-Id: I59e071c6142354a3f95730046e3dcdfc0e2c4de5
* Add with_for_update() support in session.refresh()Mike Bayer2017-05-241-3/+4
| | | | | | | | | | | | | | | Session.refresh() is still hardcoded to legacy lockmode, come up with a new API so that the newer argument style works with it. Added new argument :paramref:`.with_for_update` to the :meth:`.Session.refresh` method. When the :meth:`.Query.with_lockmode` method were deprecated in favor of :meth:`.Query.with_for_update`, the :meth:`.Session.refresh` method was never updated to reflect the new option. Change-Id: Ia02a653746b7024699b515451525a88d7a17d63a Fixes: #3991
* Add selectin loadingMike Bayer2017-04-261-0/+59
| | | | | | | | | | Adding a new kind of relationship loader that is a cross between the "immediateload" and the "subquery" eager loader, using an IN criteria to load related items in bulk immediately after the lead query result is loaded. Change-Id: If13713fba9b465865aef8fd50b5b6b977fe3ef7d Fixes: #3944
* update for 2017 copyrightMike Bayer2017-01-041-1/+1
| | | | Change-Id: I4e8c2aa8fe817bb2af8707410fa0201f938781de
* Memoize load_path in all cases, run quick populators for path changeMike Bayer2016-10-171-9/+33
| | | | | | | | | | | | | | | | | | | | | | | | Adds a new variant to the "isnew" state within entity loading for isnew=False, but the load path is new. This is to address the use case of an entity appearing in multiple places in the row in a more generalized way than the fixes in [ticket:3431], [ticket:3811] in that loading.py will be able to tell the populator that this row is not "isnew" but is a "new" path for the entity. For the moment, the new information is only being applied to the use of "quick" populators so that simple column loads can take place on top of a deferred loader from elsewhere in the row. As part of this change, state.load_path() will now always be populated with the "path" that was in effect when this state was originally loaded, which for multi-path loads of the same entity is still non-deterministic. Ideally there'd be some kind of "here's all the paths that loaded this state and how" type of data structure though it's not clear if that could be done while maintaining performance. Fixes: #3822 Change-Id: Ib915365353dfcca09e15c24001a8581113b97d5e
* - reworked the way the "select_wraps_for" expression isMike Bayer2016-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | handled within visit_select(); this attribute was added in the 1.0 series to accommodate the subquery wrapping behavior of SQL Server and Oracle while also working with positional column targeting and no longer relying upon "key fallback" in order to target columns in such a statement. The IBM DB2 third-party dialect also has this use case, but its implementation is using regular expressions to rewrite the textual SELECT only and does not make use of a "wrapped" select at this time. The logic no longer attempts to reconcile proxy set collections as this was not deterministic, and instead assumes that the select() and the wrapper select() match their columns postionally, at least for the column positions they have in common, so it is now very simple and safe. fixes #3657. - as a side effect of #3657 it was also revealed that the strategy of calling upon a ResultProxy._getter was not correctly calling into NoSuchColumnError when an expected column was not present, and instead returned None up to loading.instances() to produce NoneType failures; added a raiseerr argument to _getter() which is called when we aren't expecting None, fixes #3658.
* - happy new yearMike Bayer2016-01-291-1/+1
|
* - fix loading.py merge_result for new _merge() argumentMike Bayer2015-12-041-2/+2
|
View Lorry Controller Status