summaryrefslogtreecommitdiff
path: root/test/ext
Commit message (Collapse)AuthorAgeFilesLines
* Limit init_subclass test above python 3.6Mike Bayer2020-07-081-1/+1
| | | | | | | | The commit for I1654befe9eb1c8b8e7fc0784bdbe64284614f0ea #5357 runs the test on all Python 3 versions, however we need to limit at least python 3.6 for this. Change-Id: Ie86b78bbfd8c7bd013ff9aa7f8905328d792c1b3
* Merge "Add future=True to create_engine/Session; unify select()"mike bayer2020-07-082-19/+23
|\
| * Add future=True to create_engine/Session; unify select()Mike Bayer2020-07-082-19/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several weeks of using the future_select() construct has led to the proposal there be just one select() construct again which features the new join() method, and otherwise accepts both the 1.x and 2.x argument styles. This would make migration simpler and reduce confusion. However, confusion may be increased by the fact that select().join() is different Current thinking is we may be better off with a few hard behavioral changes to old and relatively unknown APIs rather than trying to play both sides within two extremely similar but subtly different APIs. At the moment, the .join() thing seems to be the only behavioral change that occurs without the user taking any explicit steps. Session.execute() will still behave the old way as we are adding a future flag. This change also adds the "future" flag to Session() and session.execute(), so that interpretation of the incoming statement, as well as that the new style result is returned, does not occur for existing applications unless they add the use of this flag. The change in general is moving the "removed in 2.0" system further along where we want the test suite to fully pass even if the SQLALCHEMY_WARN_20 flag is set. Get many tests to pass when SQLALCHEMY_WARN_20 is set; this should be ongoing after this patch merges. Improve the RemovedIn20 warning; these are all deprecated "since" 1.4, so ensure that's what the messages read. Make sure the inforamtion link is on all warnings. Add deprecation warnings for parameters present and add warnings to all FromClause.select() types of methods. Fixes: #5379 Fixes: #5284 Change-Id: I765a0b912b3dcd0e995426427d8bb7997cbffd51 References: #5159
* | Add **kw support to DeclarativeMeta.__init__EwenGillies2020-07-061-0/+28
|/ | | | | | | | | | | | | Added a ``**kw`` argument to the :meth:`.DeclarativeMeta.__init__` method. This allows a class to support the :pep:`487` metaclass hook ``__init_subclass__``. Pull request courtesy Ewen Gillies. Fixes: #5357 Closes: #5363 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5363 Pull-request-sha: 0ad05a768316cba03a4d312ab39d3e8fbca7ac54 Change-Id: I1654befe9eb1c8b8e7fc0784bdbe64284614f0ea
* introduce deferred lambdasMike Bayer2020-07-031-7/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The coercions system allows us to add in lambdas as arguments to Core and ORM elements without changing them at all. By allowing the lambda to produce a deterministic cache key where we can also cheat and yank out literal parameters means we can move towards having 90% of "baked" functionality in a clearer way right in Core / ORM. As a second step, we can have whole statements inside the lambda, and can then add generation with __add__(), so then we have 100% of "baked" functionality with full support of ad-hoc literal values. Adds some more short_selects tests for the moment for comparison. Other tweaks inside cache key generation as we're trying to approach a certain level of performance such that we can remove the use of "baked" from the loader strategies. As we have not yet closed #4639, however the caching feature has been fully integrated as of b0cfa7379cf8513a821a3dbe3028c4965d9f85bd, we will also add complete caching documentation here and close that issue as well. Closes: #4639 Fixes: #5380 Change-Id: If91f61527236fd4d7ae3cad1f24c38be921c90ba
* Remove _generate_path_cache_key()Mike Bayer2020-06-291-4/+5
| | | | | | | | | | loader options can now make a deterministic cache key based on the structure they are given, and this accommodates for aliased classes as well so that these cache keys are now "safe". Have baked query call upon the regular cache key method. Change-Id: Iaa2ef4064cfb16146f415ca73080f32003dd830d
* Fix a wide variety of typos and broken linksaplatkouski2020-06-251-2/+2
| | | | | | | | | | | | Note the PR has a few remaining doc linking issues listed in the comment that must be addressed separately. Signed-off-by: aplatkouski <5857672+aplatkouski@users.noreply.github.com> Closes: #5371 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5371 Pull-request-sha: 7e7d233cf3a0c66980c27db0fcdb3c7d93bc2510 Change-Id: I9c36e8d8804483950db4b42c38ee456e384c59e3
* Propose using RETURNING for bulk updates, deletesMike Bayer2020-06-231-10/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes several improvements in the area of bulk updates and deletes as well as the new session mechanics. RETURNING is now used for an UPDATE or DELETE statement emitted for a diaelct that supports "full returning" in order to satisfy the "fetch" strategy; this currently includes PostgreSQL and SQL Server. The Oracle dialect does not support RETURNING for more than one row, so a new dialect capability "full_returning" is added in addition to the existing "implicit_returning", indicating this dialect supports RETURNING for zero or more rows, not just a single identity row. The "fetch" strategy will gracefully degrade to the previous SELECT mechanics for dialects that do not support RETURNING. Additionally, the "fetch" strategy will attempt to use evaluation for the VALUES that were UPDATEd, rather than just expiring the updated attributes. Values should be evalutable in all cases where the value is not a SQL expression. The new approach also incurs some changes in the session.execute mechanics, where do_orm_execute() event handlers can now be chained to each return results; this is in turn used by the handler to detect on a per-bind basis if the fetch strategy needs to do a SELECT or if it can do RETURNING. A test suite is added to test_horizontal_shard that breaks up a single UPDATE or DELETE operation among multiple backends where some are SQLite and don't support RETURNING and others are PostgreSQL and do. The session event mechanics are corrected in terms of the "orm pre execute" hook, which now receives a flag "is_reentrant" so that the two ORM implementations for this can skip on their work if they are being called inside of ORMExecuteState.invoke(), where previously bulk update/delete were calling its SELECT a second time. In order for "fetch" to get the correct identity when called as pre-execute, it also requests the identity_token for each mapped instance which is now added as an optional capability of a SELECT for ORM columns. the identity_token that's placed by horizontal_sharding is now made available within each result row, so that even when fetching a merged result of plain rows we can tell which row belongs to which identity token. The evaluator that takes place within the ORM bulk update and delete for synchronize_session="evaluate" now supports the IN and NOT IN operators. Tuple IN is also supported. Fixes: #1653 Change-Id: I2292b56ae004b997cef0ba4d3fc350ae1dd5efc1
* Convert bulk update/delete to new execution modelMike Bayer2020-06-062-19/+169
| | | | | | | | | | | | | | | This reorganizes the BulkUD model in sqlalchemy.orm.persistence to be based on the CompileState concept and to allow plain update() / delete() to be passed to session.execute() where the ORM synchronize session logic will take place. Also gets "synchronize_session='fetch'" working with horizontal sharding. Adding a few more result.scalar_one() types of methods as scalar_one() seems like what is normally desired. Fixes: #5160 Change-Id: I8001ebdad089da34119eb459709731ba6c0ba975
* callcount reductions and refinement for cached queriesMike Bayer2020-05-283-18/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+3
| | | | | | This was accidentally pushed just now. Change-Id: I4da4151c4a81e5cf72146f8dcab3537301ccaae9
* Small callcount reductions and refinement for cached queriesMike Bayer2020-05-251-3/+3
| | | | | | | | | | | | | | | 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-252-78/+204
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-243-14/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Baked query needs to spoil fully on uncachable optionMike Bayer2020-05-041-2/+2
| | | | | | | | | | | | Fixed issue in the area of where loader options such as selectinload() interact with the baked query system, such that the caching of a query is not supposed to occur if the loader options themselves have elements such as with_polymorphic() objects in them that currently are not cache-compatible. The baked loader could sometimes not fully invalidate itself in these some of these scenarios leading to missed eager loads. Fixes: #5303 Change-Id: Iecf847204a619694d89297f83b63b613ef9767de
* Integrate new Result into ORM queryMike Bayer2020-05-022-19/+28
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Create initial 2.0 engine implementationMike Bayer2020-04-161-1/+3
| | | | | | | | | | | | | | | | | | | Implemented the SQLAlchemy 2 :func:`.future.create_engine` function which is used for forwards compatibility with SQLAlchemy 2. This engine features always-transactional behavior with autobegin. Allow execution options per statement execution. This includes that the before_execute() and after_execute() events now accept an additional dictionary with these options, empty if not passed; a legacy event decorator is added for backwards compatibility which now also emits a deprecation warning. Add some basic tests for execution, transactions, and the new result object. Build out on a new testing fixture that swaps in the future engine completely to start with. Change-Id: I70e7338bb3f0ce22d2f702537d94bb249bd9fb0a Fixes: #4644
* Pass connection to TablesTest.insert_data()Mike Bayer2020-04-155-18/+21
| | | | | | | | | | towards the goal of reducing verbosity and repetition in test fixtures as well as that we are moving to connection only for execution, move the insert_data() classmethod to accept a connection and adjust all fixtures to use it. Change-Id: I3bf534acca0d5f4cda1d4da8ae91f1155b829b09
* Use dot-separated name resolution for relationship targetMike Bayer2020-04-071-16/+91
| | | | | | | | | | | | | | | The string argument accepted as the first positional argument by the :func:`.relationship` function when using the Declarative API is no longer interpreted using the Python ``eval()`` function; instead, the name is dot separated and the names are looked up directly in the name resolution dictionary without treating the value as a Python expression. However, passing a string argument to the other :func:`.relationship` parameters that necessarily must accept Python expressions will still use ``eval()``; the documentation has been clarified to ensure that there is no ambiguity that this is in use. Fixes: #5238 Change-Id: Id802f403190adfab0ca034afe2214ba10fd9cfbb
* Run autoflush for column attribute load operationsMike Bayer2020-04-031-1/+1
| | | | | | | | | | | | | | | | | 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
* Try to measure new style caching in the ORM, take twoMike Bayer2020-04-011-0/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Supercedes: If78fbb557c6f2cae637799c3fec2cbc5ac248aaf Trying to see if by making the cache key memoized, we still can have the older "identity" form of caching which is the cheapest of all, at the same time as the newer "cache key each time" version that is not nearly as cheap; but still much cheaper than no caching at all. Also needed is a per-execution update of _keymap when we invoke from a cached select, so that Column objects that are anonymous or otherwise adapted will match up. this is analogous to the adaption of bound parameters from the cache key. Adds test coverage for the keymap / construct_params() changes related to caching. Also hones performance to a large extent for statement construction and cache key generation. Also includes a new memoized attribute approach that vastly simplifies the previous approach of "group_expirable_memoized_property" and finally integrates cleanly with _clone(), _generate(), etc. no more hardcoding of attributes is needed, as well as that most _reset_memoization() calls are no longer needed as the reset is inherent in a _generate() call; this also has dramatic performance improvements. Change-Id: I95c560ffcbfa30b26644999412fb6a385125f663
* Remove support for python 3.4Federico Caselli2020-03-301-1/+1
| | | | | | Also remove no longer used compat code Change-Id: Ifda239fd84b425e43f4028cb55a5b3b8efa4dfc6
* Deprecate plain string in execute and introduce `exec_driver_sql`Federico Caselli2020-03-211-1/+1
| | | | | | | | | | | | | | | Execution of literal sql string is deprecated in the :meth:`.Connection.execute` and a warning is raised when used stating that it will be coerced to :func:`.text` in a future release. To execute a raw sql string the new connection method :meth:`.Connection.exec_driver_sql` was added, that will retain the previous behavior, passing the string to the DBAPI driver unchanged. Usage of scalar or tuple positional parameters in :meth:`.Connection.execute` is also deprecated. Fixes: #4848 Fixes: #5178 Change-Id: I2830181054327996d594f7f0d59c157d477c3aa9
* Simplified module pre-loading strategy and made it linter friendlyFederico Caselli2020-03-071-5/+9
| | | | | | | | | | | | | | | | | 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
* Open up check for relationships that write to the same columnMike Bayer2020-02-272-5/+12
| | | | | | | | | | | | | | | Enhanced logic that tracks if relationships will be conflicting with each other when they write to the same column to include simple cases of two relationships that should have a "backref" between them. This means that if two relationships are not viewonly, are not linked with back_populates and are not otherwise in an inheriting sibling/overriding arrangement, and will populate the same foreign key column, a warning is emitted at mapper configuration time warning that a conflict may arise. A new parameter :paramref:`.relationship.overlaps` is added to suit those very rare cases where such an overlapping persistence arrangement may be unavoidable. Fixes: #5171 Change-Id: Ifae5998fc1c7e49ce059aec8a67c80cabee768ad
* Add pyprojectFederico Caselli2020-01-271-6/+8
| | | | | | | | | | | | | - Added pyproject.toml with black arguments - Updated black version in precommit hook - Reformatted the code Fixes: #5100 Closes: #5103 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5103 Pull-request-sha: 795fd5f896be4a07a2b18e6525674b815ac17593 Change-Id: I14eedbaa51fb531cbf90fcefe6a1e07c8a565625
* Add keywords to MutableList.sort()Mike Bayer2020-01-231-0/+24
| | | | | | | | Added keyword arguments to the :meth:`.MutableList.sort` function so that a key function as well as the "reverse" keyword argument can be provided. Fixes: #5114 Change-Id: Iefb29e1ccadfad6ecba558ce575029307001b88e
* Remove jython code, remove all jython / pypy symbolsMike Bayer2020-01-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | Removed all dialect code related to support for Jython and zxJDBC. Jython has not been supported by SQLAlchemy for many years and it is not expected that the current zxJDBC code is at all functional; for the moment it just takes up space and adds confusion by showing up in documentation. At the moment, it appears that Jython has achieved Python 2.7 support in its releases but not Python 3. If Jython were to be supported again, the form it should take is against the Python 3 version of Jython, and the various zxJDBC stubs for various backends should be implemented as a third party dialect. Additionally modernized logic that distinguishes between "cpython" and "pypy" to instead look at platform.python_distribution() which reliably tells us if we are cPython or not; all booleans which previously checked for pypy and sometimes jython are now converted to be "not cpython", this impacts the test suite for tests that are cPython centric. Fixes: #5094 Change-Id: I226cb55827f997daf6b4f4a755c18e7f4eb8d9ad
* Alter unique bound parameter key on deserializeMike Bayer2020-01-101-3/+55
| | | | | | | | | | | | | | Fixed bug in sqlalchemy.ext.serializer where a unique :class:`.BindParameter` object could conflict with itself if it were present in the mapping itself, as well as the filter condition of the query, as one side would be used against the non-deserialized version and the other side would use the deserialized version. Logic is added to :class:`.BindParameter` similar to its "clone" method which will uniquify the parameter name upon deserialize so that it doesn't conflict with its original. Fixes: #5086 Change-Id: Ie1edce137e92ac496c822831d038999be5d1fc2d
* Source base cleanupsMike Bayer2020-01-011-8/+5
| | | | | | | | | | | | | | | in trying to apply 2020 copyright to files, the pre-commit hooks complain about random file issues. - remove old corrections.py utility, this had something to do with repairing refs in the sphinx docs - run pre commit hooks on all files - formatting adjustments to work around code formatting collisions (long import lines that zimports can't rewrite correctly) Change-Id: I260744866f69e902eb93665c7c728ee94d3371a2
* Fix test failures under WindowsFederico Caselli2019-12-311-0/+3
| | | | | | | | | | | | | | | | | Fixed a few test failures which would occur on Windows due to SQLite file locking issues, as well as some timing issues in connection pool related tests; pull request courtesy Federico Caselli. Note the pool related issues were fixed by Mike in I1a7162e67912d22c135fa517b687a073f8fd9151 but are being ticketed here. Fixes: #4946 Closes: #5055 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5055 Pull-request-sha: 36925573aff828bbdd725a4fed5394e06c775a98 Change-Id: Ic53ec82f5d588d0e26a2d033a17c6109900d7f63
* Use expanding IN for all literal value IN expressionsMike Bayer2019-12-222-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | The "expanding IN" feature, which generates IN expressions at query execution time which are based on the particular parameters associated with the statement execution, is now used for all IN expressions made against lists of literal values. This allows IN expressions to be fully cacheable independently of the list of values being passed, and also includes support for empty lists. For any scenario where the IN expression contains non-literal SQL expressions, the old behavior of pre-rendering for each position in the IN is maintained. The change also completes support for expanding IN with tuples, where previously type-specific bind processors weren't taking effect. As part of this change, a more explicit separation between "literal execute" and "post compile" bound parameters is being made; as the "ansi bind rules" feature is rendering bound parameters inline, as we now support "postcompile" generically, these should be used here, however we have to render literal values at execution time even for "expanding" parameters. new test fixtures etc. are added to assert everything goes to the right place. Fixes: #4645 Change-Id: Iaa2b7bfbfaaf5b80799ee17c9b8507293cba6ed1
* Don't apply aliasing + adaption for simple relationship joinsMike Bayer2019-12-191-1/+0
| | | | | | | | | | | Identified a performance issue in the system by which a join is constructed based on a mapped relationship. The clause adaption system would be used for the majority of join expressions including in the common case where no adaptation is needed. The conditions under which this adaptation occur have been refined so that average non-aliased joins along a simple relationship without a "secondary" table use about 70% less function calls. Change-Id: Ifbe04214576e5a9fac86ca80c1dc7145c27cd50a
* Generalize DescriptorProps.uses_objectsMike Bayer2019-11-231-2/+71
| | | | | | | | | | | | | | | | Previously, uses_objects was specific to the SynonymAttribute; generalize it so that it defaults to False for other DescriptorProps. Immediate fix is against CompositeProperty. Fixed regression introduced in 1.3.0 related to the association proxy refactor in :ticket:`4351` that prevented :func:`.composite` attributes from working in terms of an association proxy that references them. Add test coverage for association proxies that refer to Composite attributes as endpoints. Fixes: #5000 Change-Id: Iea6fb1bd3314d861a9bc22491b0ae1e6c5e6340d
* Add anonymizing context to cache keys, comparison; convert traversalMike Bayer2019-11-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Created new visitor system called "internal traversal" that applies a data driven approach to the concept of a class that defines its own traversal steps, in contrast to the existing style of traversal now known as "external traversal" where the visitor class defines the traversal, i.e. the SQLCompiler. The internal traversal system now implements get_children(), _copy_internals(), compare() and _cache_key() for most Core elements. Core elements with special needs like Select still implement some of these methods directly however most of these methods are no longer explicitly implemented. The data-driven system is also applied to ORM elements that take part in SQL expressions so that these objects, like mappers, aliasedclass, query options, etc. can all participate in the cache key process. Still not considered is that this approach to defining traversibility will be used to create some kind of generic introspection system that works across Core / ORM. It's also not clear if real statement caching using the _cache_key() method is feasible, if it is shown that running _cache_key() is nearly as expensive as compiling in any case. Because it is data driven, it is more straightforward to optimize using inlined code, as is the case now, as well as potentially using C code to speed it up. In addition, the caching sytem now accommodates for anonymous name labels, which is essential so that constructs which have anonymous labels can be cacheable, that is, their position within a statement in relation to other anonymous names causes them to generate an integer counter relative to that construct which will be the same every time. Gathering of bound parameters from any cache key generation is also now required as there is no use case for a cache key that does not extract bound parameter values. Applies-to: #4639 Change-Id: I0660584def8627cad566719ee98d3be045db4b8d
* Don't cache a query that has before_compile modificationsMike Bayer2019-10-261-0/+108
| | | | | | | | | | | | | | | | | The :class:`.BakedQuery` will not cache a query that was modified by a :meth:`.QueryEvents.before_compile` event, so that compilation hooks that may be applying ad-hoc modifications to queries will take effect on each run. In particular this is helpful for events that modify queries used in lazy loading as well as eager loading such as "select in" loading. In order to re-enable caching for a query modified by this event, a new flag ``bake_ok`` is added; see :ref:`baked_with_before_compile` for details. A longer term plan to provide a new form of SQL caching should solve this kind of issue more comprehensively. Fixes: #4947 Change-Id: I5823c4fa00e7b6d46a2e8461b02d8b16605a6ed0
* Implement raiseload for deferred columnsMike Bayer2019-10-161-1/+1
| | | | | | | | | | | | | | | | | | | | | 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
* Add result map targeting for custom compiled, text objectsMike Bayer2019-10-071-5/+49
| | | | | | | | | | | | | | | | In order for text(), custom compiled objects, etc. to be usable by Query(), they are all targeted by object key in the result map. As we no longer want Query to implicitly label these, as well as that text() has no label feature, support adding entries to the result map that have no name, key, or type, only the object itself, and then ensure that the compiler sets up for positional targeting when this condition is detected. Allows for more flexible ORM query usage with custom expressions and text() while having less special logic in query itself. Fixes: #4887 Change-Id: Ie073da127d292d43cb132a2b31bc90af88bfe2fd
* Unify generation between Core and ORM queryMike Bayer2019-09-261-1/+1
| | | | | | | | | | | | | | generation is to be enhanced to include caching functionality, so ensure that Query and all generative in Core (e.g. select, DML etc) are using the same generations system. Additionally, deprecate Select.append methods and state Select methods independently of their append versions. Mutability of expression objects is a special case only when generating new objects during a visit. Fixes: #4637 Change-Id: I3dfac00d5e0f710c833b236f7a0913e1ca24dde4
* Merge "Modernize internal reflection"mike bayer2019-08-071-0/+43
|\
| * Modernize internal reflectionMike Bayer2019-08-061-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Deprecated remaining engine-level introspection and utility methods including :meth:`.Engine.run_callable`, :meth:`.Engine.transaction`, :meth:`.Engine.table_names`, :meth:`.Engine.has_table`. The utility methods are superseded by modern context-manager patterns, and the table introspection tasks are suited by the :class:`.Inspector` object. - The internal dialect method ``Dialect.reflecttable`` has been removed. A review of third party dialects has not found any making use of this method, as it was already documented as one that should not be used by external dialects. Additionally, the private ``Engine._run_visitor`` method is also removed. - The long-deprecated ``Inspector.get_table_names.order_by`` parameter has been removed. - The :paramref:`.Table.autoload_with` parameter now accepts an :class:`.Inspector` object directly, as well as any :class:`.Engine` or :class:`.Connection` as was the case before. Fixes: #4755 Change-Id: Iec3a8b0f3e298ba87d532b16fac1e1132f464e21
* | Remove threadlocal strategy docs, remaining contextual_connectMike Bayer2019-08-051-1/+9
|/ | | | | | | | | | | | in dfb20f07d8, we merged the removal of the threadlocal strategy from the 1.4 branch. We forgot to take the docs out :). Also, there seems to be an uncovered _contextual_connect call in horizontal shard. Cover that and repair. Fixes: #4632 Closes: #4795 Change-Id: Id05cbbebe34a8f547c9c84369a929a2926c7d093
* Enable F841Mike Bayer2019-06-202-2/+2
| | | | | | | | | | | This is a very useful assertion which prevents unused variables from being set up allows code to be more readable and sometimes even more efficient. test suites seem to be where the most problems are and there do not seem to be documentation examples that are using this, or at least the linter is not taking effect within rst blocks. Change-Id: I2b3341d8dd14da34879d8425838e66a4b9f8e27d
* Consult is_attrbute flag to determine descriptor; enable for assoc proxyMike Bayer2019-06-141-0/+9
| | | | | | | | | | | | Fixed bug where the :attr:`.Mapper.all_orm_descriptors` accessor would return an entry for the :class:`.Mapper` itself under the declarative ``__mapper___`` key, when this is not a descriptor. The ``.is_attribute`` flag that's present on all :class:`.InspectionAttr` objects is now consulted, which has also been modified to be ``True`` for an association proxy, as it was erroneously set to False for this object. Fixes: #4729 Change-Id: Ia02388cc25d004e32d337140b62a587f3e5a0b7b
* Adjust test_concurrency failure modesMike Bayer2019-05-271-5/+17
| | | | | | | | | The test added for #4686 can raise for "B" missing which is normal and should not fail the test. Also ensure mappers are cleared to prevent subsequent tests elsewhere from being affected. Change-Id: I4c5791223e7fd21e04dcd095daa7d868e77dbd97
* Add QueryableAttribute._impl_uses_objects accessor for AssociationProxyMike Bayer2019-05-191-8/+43
| | | | | | | | | | | | | | Fixed regression where new association proxy system was still not proxying hybrid attributes when they made use of the ``@hybrid_property.expression`` decorator to return an alternate SQL expression, or when the hybrid returned an arbitrary :class:`.PropComparator`, at the expression level. This involved futher generalization of the heuristics used to detect the type of object being proxied at the level of :class:`.QueryableAttribute`, to better detect if the descriptor ultimately serves mapped classes or column expressions. Fixes: #4690 Change-Id: I5b5300661291c94a23de53bcf92d747701720aa1
* Implement new ClauseElement role and coercion systemMike Bayer2019-05-183-10/+12
| | | | | | | | | | | | | | | | | | | | A major refactoring of all the functions handle all detection of Core argument types as well as perform coercions into a new class hierarchy based on "roles", each of which identify a syntactical location within a SQL statement. In contrast to the ClauseElement hierarchy that identifies "what" each object is syntactically, the SQLRole hierarchy identifies the "where does it go" of each object syntactically. From this we define a consistent type checking and coercion system that establishes well defined behviors. This is a breakout of the patch that is reorganizing select() constructs to no longer be in the FromClause hierarchy. Also includes a rename of as_scalar() into scalar_subquery(); deprecates automatic coercion to scalar_subquery(). Partially-fixes: #4617 Change-Id: I26f1e78898693c6b99ef7ea2f4e7dfd0e8e1a1bd
* Mutex the declarative scan/map process against configure_mappers()Mike Bayer2019-05-161-0/+78
| | | | | | | | | | | | | Applied the mapper "configure mutex" against the declarative class mapping process, to guard against the race which can occur if mappers are used while dynamic module import schemes are still in the process of configuring mappers for related classes. This does not guard against all possible race conditions, such as if the concurrent import has not yet encountered the dependent classes as of yet, however it guards against as much as possible within the SQLAlchemy declarative process. Fixes: #4686 Change-Id: I0349036b8078bd42265ab40862cfbfe5bf9d5b44
* Reimplement .compare() in terms of a visitorMike Bayer2019-04-291-0/+12
| | | | | | | | | | | | Reworked the :meth:`.ClauseElement.compare` methods in terms of a new visitor-based approach, and additionally added test coverage ensuring that all :class:`.ClauseElement` subclasses can be accurately compared against each other in terms of structure. Structural comparison capability is used to a small degree within the ORM currently, however it also may form the basis for new caching features. Fixes: #4336 Change-Id: I581b667d8e1642a6c27165cc9f4aded1c66effc6
* Add __reduce_ex__ to MutableList; add compat for older picklesMike Bayer2019-04-091-0/+94
| | | | | | | | | | | | | | | | | | Fixed bug where using ``copy.copy()`` or ``copy.deepcopy()`` on :class:`.MutableList` would cause the items within the list to be duplicated, due to an inconsistency in how Python pickle and copy both make use of ``__getstate__()`` and ``__setstate__()`` regarding lists. In order to resolve, a ``__reduce_ex__`` method had to be added to :class:`.MutableList`. In order to maintain backwards compatibility with existing pickles based on ``__getstate__()``, the ``__setstate__()`` method remains as well; the test suite asserts that pickles made against the old version of the class can still be deserialized by the pickle module. Also modified sqlalchemy.testing.util.picklers to return picklers all the way through pickle.HIGHEST_PROTOCOL. Fixes: #4603 Change-Id: I7f78b9cfb89d59a706248536c553dc5e1d987b88
View Lorry Controller Status