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
The ``lazy="select"`` loader strategy now makes used of the :class:`.BakedQuery` query caching system in all cases. This removes most overhead of generating a :class:`.Query` object and running it into a :func:`.select` and then string SQL statement from the process of lazy-loading related collections and objects. The "baked" lazy loader has also been improved such that it can now cache in most cases where query load options are used. Change-Id: Ic96792fffaa045ae9aa0a4657d6d29235d3efb85 Fixes: #3954
Change-Id: I7f9a1265664b0368ee7a771d01c7ca1612156d1f
when the suite runs, such as a background thread or something like that, which is affecting these tests a bit. Change-Id: I52d50a44778ec1eecb8e335ae59b1a4773e80a79
Added warnings to the LRU "compiled cache" used by the :class:`.Mapper` (and ultimately will be for other ORM-based LRU caches) such that when the cache starts hitting its size limits, the application will emit a warning that this is a performance-degrading situation that may require attention. The LRU caches can reach their size limits primarily if an application is making use of an unbounded number of :class:`.Engine` objects, which is an antipattern. Otherwise, this may suggest an issue that should be brought to the SQLAlchemy developer's attention. Additionally, adjusted the test_memusage algorithm again as the previous one could still allow a growing memory size to be missed. Change-Id: I020d1ceafb7a08f6addfa990a1e7acd09f933240
Fixed bug in compiler where the string identifier of a savepoint would be cached in the identifier quoting dictionary; as these identifiers are arbitrary, a small memory leak could occur if a single :class:`.Connection` had an unbounded number of savepoints used, as well as if the savepoint clause constructs were used directly with an unbounded umber of savepoint names. The memory leak does **not** impact the vast majority of cases as normally the :class:`.Connection`, which renders savepoint names with a simple counter starting at "1", is used on a per-transaction or per-fixed-number-of-transactions basis before being discarded. The savepoint name in virtually all cases does not require quoting at all, however to support potential third party use cases the "check for quotes needed" logic is retained, at a small performance cost. Uncondtionally quoting the name is another option, but this would turn the name into a case sensitive name which runs the risk of poor interactions with existing deployments that may be looking at these names in other contexts. Change-Id: I6b53c96abf7fdf1840592bbca5da81347911844c Fixes: #3931
Continuing from Ie43beecf37945b2bb7fff0aaa597a597293daa18, also observed is the overhead of PathRegsitry memoized token functions, as these paths are not cached in the case of long joinedloader chains. The memoizations here were made with short paths in mind, and have been replaced with an inlined straight create of these paths up front, producing callcounts very similar to 0.8. Combined with the previous optimizations, 1.1 now runs the "joined eager load of one row" worst case test in about 40% fewer calls than 0.8 and 60% fewer than 1.1.5. Change-Id: Ib5e1c1345a1dd8edfbdb3fed06eb717d4e164d31 Fixes: #3915
Addressed some long unattended performance concerns within the joined eager loader query construction system. The use of ad-hoc :class:`.AliasedClass` objects per query, which produces lots of column lookup overhead each time, has been replaced with a cached approach that makes use of a small pool of :class:`.AliasedClass` objects that are reused between invocations of joined eager loading. Callcount reduction of SQL query generation for worst-case joined loader scenarios (lots of joins, lots of columns) is reduced by approximately 270%. Change-Id: Ie43beecf37945b2bb7fff0aaa597a597293daa18 Fixes: #3915
tested using pycodestyle version 2.2.0 Fixes: #3885 Change-Id: I5df43adc3aefe318f9eeab72a078247a548ec566 Pull-request: https://github.com/zzzeek/sqlalchemy/pull/343
This is an old parameter no longer relevant to how SQLAlchemy works, once the Query object was introduced. By deprecating it we establish that we aren't supporting non-working use cases and that we encourage applications to move off of the use of this parameter. Fixes: #3394 Change-Id: I25b9a38142a1537bbcb27d3e8b66a8b265140072