summaryrefslogtreecommitdiff
path: root/test/sql
Commit message (Collapse)AuthorAgeFilesLines
...
* Query linter optionAlessio Bogon2020-01-223-19/+315
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added "from linting" as a built-in feature to the SQL compiler. This allows the compiler to maintain graph of all the FROM clauses in a particular SELECT statement, linked by criteria in either the WHERE or in JOIN clauses that link these FROM clauses together. If any two FROM clauses have no path between them, a warning is emitted that the query may be producing a cartesian product. As the Core expression language as well as the ORM are built on an "implicit FROMs" model where a particular FROM clause is automatically added if any part of the query refers to it, it is easy for this to happen inadvertently and it is hoped that the new feature helps with this issue. The original recipe is from: https://github.com/sqlalchemy/sqlalchemy/wiki/FromLinter The linter is now enabled for all tests in the test suite as well. This has necessitated that a lot of the queries be adjusted to not include cartesian products. Part of the rationale for the linter to not be enabled for statement compilation only was to reduce the need for adjustment for the many test case statements throughout the test suite that are not real-world statements. This gerrit is adapted from Ib5946e57c9dba6da428c4d1dee6760b3e978dda0. Fixes: #4737 Change-Id: Ic91fd9774379f895d021c3ad564db6062299211c Closes: #4830 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4830 Pull-request-sha: f8a21aa6262d1bcc9ff0d11a2616e41fba97a47a
* Merge "apply asbool reduction to the onclause in join()"mike bayer2020-01-181-0/+37
|\
| * apply asbool reduction to the onclause in join()Mike Bayer2020-01-171-0/+37
| | | | | | | | | | | | | | | | | | | | The :func:`.true` and :func:`.false` operators may now be applied as the "onclause" of a :func:`.sql.join` on a backend that does not support "native boolean" expressions, e.g. Oracle or SQL Server, and the expression will render as "1=1" for true and "1=0" false. This is the behavior that was introduced many years ago in :ticket:`2804` for and/or expressions. Change-Id: I85311c31c22d6e226c618f8840f6b95eca611153
* | Remove jython code, remove all jython / pypy symbolsMike Bayer2020-01-171-1/+0
|/ | | | | | | | | | | | | | | | | | | | | | 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
* Support GenericFunction.name passed as a quoted_nameMike Bayer2020-01-061-0/+16
| | | | | | | | | | | | | | | A function created using :class:`.GenericFunction` can now specify that the name of the function should be rendered with or without quotes by assigning the :class:`.quoted_name` construct to the .name element of the object. Prior to 1.3.4, quoting was never applied to function names, and some quoting was introduced in :ticket:`4467` but no means to force quoting for a mixed case name was available. Additionally, the :class:`.quoted_name` construct when used as the name will properly register its lowercase name in the function registry so that the name continues to be available via the ``func.`` registry. Fixes: #5079 Change-Id: I0653ab8b16e75e628ce82dbbc3d0f77f8336c407
* Source base cleanupsMike Bayer2020-01-011-2/+2
| | | | | | | | | | | | | | | 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
* Test for short term reference cycles and resolve as many as possibleMike Bayer2019-12-301-2/+2
| | | | | | | | Added test support and repaired a wide variety of unnecessary reference cycles created for short-lived objects, mostly in the area of ORM queries. Fixes: #5056 Change-Id: Ifd93856eba550483f95f9ae63d49f36ab068b85a
* Use expanding IN for all literal value IN expressionsMike Bayer2019-12-225-190/+204
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Copy bind_processors when altering for expanding INMike Bayer2019-12-201-0/+46
| | | | | | | | | | | | | | | | Fixed issue where the collection of value processors on a :class:`.Compiled` object would be mutated when "expanding IN" parameters were used with a datatype that has bind value processors; in particular, this would mean that when using statement caching and/or baked queries, the same compiled._bind_processors collection would be mutated concurrently. Since these processors are the same function for a given bind parameter namespace every time, there was no actual negative effect of this issue, however, the execution of a :class:`.Compiled` object should never be causing any changes in its state, especially given that they are intended to be thread-safe and reusable once fully constructed. Fixes: #5048 Change-Id: I876d16bd7484eb05ce590397420552ac36da6e52
* Implement random_choices for Python 2Mike Bayer2019-12-201-2/+3
| | | | | | | Apparently py2k has no random.choices, so make a quick one for the tests that use it. Change-Id: Iadc3442b35f400b5bab0f711b7d3ede5dbc28f52
* Ensure comparison includes "don't compare values" featureMike Bayer2019-12-201-70/+127
| | | | | | | | | | upcoming changes for "expanding IN in all cases" and "lambda elements" both rely upon comparisons that work across changing bound values, so commit the testing fixture ahead of time. Additionally, repair the feature itself within traversals. Change-Id: Ie65a512dc64745614180da77435f9f745ce78c71
* Add CTE prefixesMarat Sharafutdinov2019-12-181-0/+22
| | | | | | | | | | | | | Added support for prefixes to the :class:`.CTE` construct, to allow support for Postgresql 12 "MATERIALIZED" and "NOT MATERIALIZED" phrases. Pull request courtesy Marat Sharafutdinov. Fixes: #5040 Closes: #5043 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5043 Pull-request-sha: d1b9059a0b6dae8dc2479ac670999b4af07908e0 Change-Id: I2e9cb5d7f85961ec98ee51965de5b3ec4a97be2f
* Do the CompoundSelect check for number of columns in the compile phaseMike Bayer2019-12-161-4/+2
| | | | | | | | Starting to go forward with the general idea of moving more of Core / ORM construction into the compile phase. Bigger initiatives like the refactor of Query will follow onto this. Change-Id: I0f364d3182e21e32ed85ef34cfd11fd9d11cf653
* Ensure cache keys are hashable in the testMike Bayer2019-12-141-0/+1
| | | | Change-Id: I962ff15194e2416844086f03dddadb49f48a6c8d
* Use label reference coercion for select() distinct keyword argumentMike Bayer2019-12-061-0/+9
| | | | | | | | | | | Fixed bug where "distinct" keyword passed to :func:`.select` would not treat a string value as a "label reference" in the same way that the :meth:`.select.distinct` does; it would instead raise unconditionally. This keyword argument and the others passed to :func:`.select` will ultimately be deprecated for SQLAlchemy 2.0. Fixes: #5028 Change-Id: Id36cfe477ed836c3248824ce1b81d0016dbe99f4
* Include DISTINCT in error message for label referenceMike Bayer2019-12-062-4/+23
| | | | | | | | Needed to add tests to ensure this label reference is handled correctly, so also modified the exception message to be more clear if someone has this error within distinct(). Change-Id: I6e685e46ae336596272d14366445ac224c18d92c
* Merge "Remove ORM elements from annotations at the schema level."mike bayer2019-11-261-4/+81
|\
| * Remove ORM elements from annotations at the schema level.Mike Bayer2019-11-261-4/+81
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where when constructing constraints from ORM-bound columns, primarily :class:`.ForeignKey` objects but also :class:`.UniqueConstraint`, :class:`.CheckConstraint` and others, the ORM-level :class:`.InstrumentedAttribute` is discarded entirely, and all ORM-level annotations from the columns are removed; this is so that the constraints are still fully pickleable without the ORM-level entities being pulled in. These annotations are not necessary to be present at the schema/metadata level. Fully implemented coercions for constraint columns within schema.py, including for FK referenced columns. Fixes: #5001 Change-Id: I895400dd979310be034085d207f096707c635909
* | Add sequence support for MariaDB 10.3+.Gord Thompson2019-11-261-12/+62
|/ | | | | | | | | | | | | | | | | | | | Added support for use of the :class:`.Sequence` construct with MariaDB 10.3 and greater, as this is now supported by this database. The construct integrates with the :class:`.Table` object in the same way that it does for other databases like PostrgreSQL and Oracle; if is present on the integer primary key "autoincrement" column, it is used to generate defaults. For backwards compatibility, to support a :class:`.Table` that has a :class:`.Sequence` on it to support sequence only databases like Oracle, while still not having the sequence fire off for MariaDB, the optional=True flag should be set, which indicates the sequence should only be used to generate the primary key if the target database offers no other option. Fixes: #4976 Closes: #4996 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4996 Pull-request-sha: cb2e1426ea0b6bc6c93dbe8f033a11df9d8c4915 Change-Id: I507bc405eee6cae2c5991345d0eac53a37fe7512
* Repair Oracle IntervalMike Bayer2019-11-111-19/+17
| | | | | | | | | | | The :class:`.oracle.INTERVAL` class of the Oracle dialect is now correctly a subclass of the abstract version of :class:`.Interval` as well as the correct "emulated" base class, which allows for correct behavior under both native and non-native modes; previously it was only based on :class:`.TypeEngine`. Fixes: #4971 Change-Id: I4400d9f090330388460cca930e4139e3bd21eb11
* Add type accessors for JSON indexed/pathed element accessMike Bayer2019-11-111-0/+42
| | | | | | | | | | | | | | | Added new accessors to expressions of type :class:`.JSON` to allow for specific datatype access and comparison, covering strings, integers, numeric, boolean elements. This revises the documented approach of CASTing to string when comparing values, instead adding specific functionality into the PostgreSQL, SQlite, MySQL dialects to reliably deliver these basic types in all cases. The change also delivers a new feature to the test exclusions system so that combinations and exclusions can be used together. Fixes: #4276 Change-Id: Ica5a926c060feb40a0a7cd60b9d6e061d7825728
* Fix exclusions for multiple fails_onMike Bayer2019-11-091-41/+19
| | | | | | | | | | | | | | The fails_on decorator was not being interpreted correctly when multiple were present. Remove obsolete fails_on from test_types that no longer take place for MySQL, Oracle. Ensure test_types tests are using __backend__ mark currently failing Oracle interval tests Change-Id: If8db0c02b31a8008fd1673c2380f1f974c3806a6
* Support for generated columnsCaselIT2019-11-082-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | Added DDL support for "computed columns"; these are DDL column specifications for columns that have a server-computed value, either upon SELECT (known as "virtual") or at the point of which they are INSERTed or UPDATEd (known as "stored"). Support is established for Postgresql, MySQL, Oracle SQL Server and Firebird. Thanks to Federico Caselli for lots of work on this one. ORM round trip tests included. The ORM makes use of existing FetchedValue support and no additional ORM logic is present for the basic feature. It has been observed that Oracle RETURNING does not return the new value of a computed column upon UPDATE; it returns the prior value. As this is very dangerous, a warning is emitted if a computed column is rendered into the RETURNING clause of an UPDATE statement. Fixes: #4894 Closes: #4928 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4928 Pull-request-sha: d39c521d5ac6ebfb4fb5b53846451de79752e64c Change-Id: I2610b2999a5b1b127ed927dcdaeee98b769643ce
* Add anonymizing context to cache keys, comparison; convert traversalMike Bayer2019-11-045-152/+427
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use simple growth scale with any max size for BufferedRowResultProxysumau2019-10-301-23/+39
| | | | | | | | | | | | | | | | | The maximum buffer size for the :class:`.BufferedRowResultProxy`, which is used by dialects such as PostgreSQL when ``stream_results=True``, can now be set to a number greater than 1000 and the buffer will grow to that size. Previously, the buffer would not go beyond 1000 even if the value were set larger. The growth of the buffer is also now based on a simple multiplying factor currently set to 5. Pull request courtesy Soumaya Mauthoor. Fixes: #4914 Closes: #4930 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4930 Pull-request-sha: 66841f56e967c784f7078a787cec5129462006c8 Change-Id: I6286220bd9d488027fadc444039421a410e19a19
* Use default repr() for quoted_name under python 3Mike Bayer2019-10-242-11/+70
| | | | | | | | | | | | | | | | | | | | | Changed the ``repr()`` of the :class:`.quoted_name` construct to use regular string repr() under Python 3, rather than running it through "backslashreplace" escaping, which can be misleading. Modified the approach of "name normalization" for the Oracle and Firebird dialects, which converts from the UPPERCASE-as-case-insensitive convention of these dialects into lowercase-as-case-insensitive for SQLAlchemy, to not automatically apply the :class:`.quoted_name` construct to a name that matches itself under upper or lower case conversion, as is the case for many non-european characters. All names used within metadata structures are converted to :class:`.quoted_name` objects in any case; the change here would only affect the output of some inspection functions. Moved name normalize to be under default dialect, added test coverage in test/sql/test_quote.py Fixes: #4931 Change-Id: Ic121b20e07249824710a54423e321d94a425362f
* Implement facade for pytest parametrize, fixtures, classlevelMike Bayer2019-10-202-393/+355
| | | | | | | | | | | | | | | | | | | Add factilities to implement pytest.mark.parametrize and pytest.fixtures patterns, which largely resemble things we are already doing. Ensure a facade is used, so that the test suite remains independent of py.test, but also tailors the functions to the more limited scope in which we are using them. Additionally, create a class-based version that works from the same facade. Several old polymorphic tests as well as two of the sql test are refactored to use the new features. Change-Id: I6ef8af1dafff92534313016944d447f9439856cf References: #4896
* Use separate label generator for column_label naming conventionMike Bayer2019-10-142-6/+132
| | | | | | | | | | | | | | | | | | | | Fixed bug where a table that would have a column label overlap with a plain column name, such as "foo.id AS foo_id" vs. "foo.foo_id", would prematurely generate the ``._label`` attribute for a column before this overlap could be detected due to the use of the ``index=True`` or ``unique=True`` flag on the column in conjunction with the default naming convention of ``"column_0_label"``. This would then lead to failures when ``._label`` were used later to generate a bound parameter name, in particular those used by the ORM when generating the WHERE clause for an UPDATE statement. The issue has been fixed by using an alternate ``._label`` accessor for DDL generation that does not affect the state of the :class:`.Column`. The accessor also bypasses the key-deduplication step as it is not necessary for DDL, the naming is now consistently ``"<tablename>_<columnname>"`` without any subsequent numeric symbols when used in DDL. Fixes: #4911 Change-Id: Iabf5fd3250738d800d6e41a2a3a27a7ce2405e7d
* Add _alembic_quote method to format_constraint()Mike Bayer2019-10-131-0/+28
| | | | | | | | | | | | | | Alembic needs a portable way of getting at the name of an index without quoting being applied. As we would like the indexes created by the Column index=True flag to support deferred index names, supply a function that delivers this for Alembic without it having to dig too deeply into the internals. the _alembic_quote flag may be made public at a later time, however as we've been through many quoting flags that are difficult to get rid of, try to be conservative to start. Change-Id: I184adaeae26c2e75093aaea5ebe01a3815cadb08
* Merge "Remove deprecated elements"mike bayer2019-10-111-158/+0
|\
| * Remove deprecated elementsAsif Saif Uddin (Auvi)2019-10-111-158/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Includes: PassiveDefault SchemaItem.quote Table.useexisting Table.quote_schema Table.append_ddl_listener MetaData.append_ddl_listener Metadata.reflect kw parameter (use reflect() method) DDL.execute_at DDL.on Partially-fixes: #4643 Closes: #4893 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/4893 Pull-request-sha: 860eb6a253fe4a95685b4f5f3349b19823a304f3 Change-Id: I0f5b8a873e7581365ff8dba48eab358d9e8e7b13
* | Omit onclause as source of FROMs from a JoinMike Bayer2019-10-091-0/+26
|/ | | | | | | | | | | | | The :class:`.Join` construct no longer considers the "onclause" as a source of additional FROM objects to be omitted from the FROM list of an enclosing :class:`.Select` object as standalone FROM objects. This applies to an ON clause that includes a reference to another FROM object outside the JOIN; while this is usually not correct from a SQL perspective, it's also incorrect for it to be omitted, and the behavioral change makes the :class:`.Select` / :class:`.Join` behave a bit more intuitively. Fixes: #4621 Change-Id: Iaa1e75b7c59b21e9701ab3c9b69e66930feaf8ee
* Merge "Add result map targeting for custom compiled, text objects"mike bayer2019-10-083-10/+198
|\
| * Add result map targeting for custom compiled, text objectsMike Bayer2019-10-073-10/+198
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Merge "Fix max_identifier_length for SQL server"mike bayer2019-10-071-0/+1
|\ \ | |/ |/|
| * Fix max_identifier_length for SQL serverMike Bayer2019-10-071-0/+1
| | | | | | | | | | | | | | | | | | Fixed bug in SQL Server dialect with new "max_identifier_length" feature where the mssql dialect already featured this flag, and the implementation did not accommodate for the new initialization hook correctly. Fixes: #4857 Change-Id: I96a9c6ca9549d8f6fb167c0333f684e8d922a3bf
* | Drop right-nested join rewritingMike Bayer2019-10-071-838/+0
|/ | | | | | | | | | Dropped support for right-nested join rewriting to support old SQLite versions prior to 3.7.16, released in 2013. It is expected that all modern Python versions among those now supported should all include much newer versions of SQLite. Fixes: #4895 Change-Id: I7f0cfc2b7d988ff147b9a4c6d5e2adec87e27029
* create second level deduping when use_labels is turned onMike Bayer2019-10-074-29/+196
| | | | | | | | | | | | | | | | | | | | | As of #4753 we allow duplicate columns. This creates some new problems that there can be duplicate columns in a subquery which are then not addressible on the outside because they are ambiguous (Postgresql has this behavior at least). Additionally it creates situations where we are making an anon label of an anon label which is leaking into the query. New logic for generating anon labels handles this situation and also alters the .c collection of a subquery such that we are only getting the first column from the derived selectable that has that name, the subsequent ones have a new deduping label with two underscores and are not exposed in .c. The dedupe logic when rendering the columns will handle duplicate label names for different columns, vs. the same column repeated, as separate cases. Fixes: #4892 Change-Id: I929fbd8da14bcc239e0481c24bbd9b5ce826e8fa
* Merge "Deprecate textual column matching in Row"mike bayer2019-10-054-119/+614
|\
| * Deprecate textual column matching in RowMike Bayer2019-10-044-119/+614
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Deprecate query.instances() without a context Deprecate string alias with contains_eager() Deprecated the behavior by which a :class:`.Column` can be used as the key in a result set row lookup, when that :class:`.Column` is not part of the SQL selectable that is being selected; that is, it is only matched on name. A deprecation warning is now emitted for this case. Various ORM use cases, such as those involving :func:`.text` constructs, have been improved so that this fallback logic is avoided in most cases. Calling the :meth:`.Query.instances` method without passing a :class:`.QueryContext` is deprecated. The original use case for this was that a :class:`.Query` could yield ORM objects when given only the entities to be selected as well as a DBAPI cursor object. However, for this to work correctly there is essential metadata that is passed from a SQLAlchemy :class:`.ResultProxy` that is derived from the mapped column expressions, which comes originally from the :class:`.QueryContext`. To retrieve ORM results from arbitrary SELECT statements, the :meth:`.Query.from_statement` method should be used. Note there is a small bump in test_zoomark because the column._label is being calculated for each of those columns within baseline_3_properties, as it is now part of the result map. This label can't be calculated when the column is attached to the table because it needs to have all the columns present to do this correctly. Another approach here would be to pre-load the _label before the test runs however the zoomark tests don't have an easy place for this to happen and it's not really worth it. Fixes: #4877 Fixes: #4719 Change-Id: I9bd29e72e6dce7c855651d69ba68d7383469acbc
* | Add max_identifier_length parameter; warn for OracleMike Bayer2019-10-021-3/+124
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added new :func:`.create_engine` parameter :paramref:`.create_engine.max_identifier_length`. This overrides the dialect-coded "max identifier length" in order to accommodate for databases that have recently changed this length and the SQLAlchemy dialect has not yet been adjusted to detect for that version. This parameter interacts with the existing :paramref:`.create_engine.label_length` parameter in that it establishes the maximum (and default) value for anonymously generated labels. The Oracle dialect now emits a warning if Oracle version 12.2 or greater is used, and the :paramref:`.create_engine.max_identifier_length` parameter is not set. The version in this specific case defaults to that of the "compatibility" version set in the Oracle server configuration, not the actual server version. In version 1.4, the default max_identifier_length for 12.2 or greater will move to 128 characters. In order to maintain forwards compatibility, applications should set :paramref:`.create_engine.max_identifier_length` to 30 in order to maintain the same length behavior, or to 128 in order to test the upcoming behavior. This length determines among other things how generated constraint names are truncated for statements like ``CREATE CONSTRAINT`` and ``DROP CONSTRAINT``, which means a the new length may produce a name-mismatch against a name that was generated with the old length, impacting database migrations. Fixes: #4857 Change-Id: Ib62efb00c6180c375869029b57353d90385d7950
* Run row value processors up frontMike Bayer2019-10-012-18/+31
| | | | | | | | | | | | 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
* Unify generation between Core and ORM queryMike Bayer2019-09-265-17/+118
| | | | | | | | | | | | | | 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
* Restore subquery.as_scalar() w/ deprecationMike Bayer2019-09-111-0/+9
| | | | | | | | Apparently Alias had an .as_scalar() method, so restore an equivalent to Subquery with an appropriate deprecation warning. Fixes: #4854 Change-Id: I6255d61b7d82487ca90ba8ee79d4b3a74e7cbe38
* Catch set_parent_w_dispatch missingMike Bayer2019-09-061-0/+31
| | | | | | | | | Added an explicit error message for the case when objects passed to :class:`.Table` are not :class:`.SchemaItem` objects, rather than resolving to an attribute error. Fixes: #4847 Change-Id: I4dcdcee86b64c85ccf12e2ddc3d638563d307991
* Adjustments to _copy_internals()Mike Bayer2019-09-061-3/+13
| | | | | | | | | | | | We are looking to build a generalization of copy_internals(), so move out any special logic from these methods. Re-implement and clarify rationale for the Alias doesnt copy a TableClause rule as part of the adaption traversal, establish that we forgot to build out comparison and cache key for CTE, remove incomplete _copy_internals() from GenerativeSelect (it doesn't handle the order_by_clause or group_by_clause, so is incomplete) Change-Id: I95039f042503171aade4ba0fabc9b1598e3c49cf
* Strip special chars in anonymized bind namesMike Bayer2019-09-051-0/+54
| | | | | | | | | | | | | | | | | | | | | | Characters that interfere with "pyformat" or "named" formats in bound parameters, namely ``%, (, )`` and the space character, as well as a few other typically undesirable characters, are stripped early for a :func:`.bindparam` that is using an anonymized name, which is typically generated automatically from a named column which itself includes these characters in its name and does not use a ``.key``, so that they do not interfere either with the SQLAlchemy compiler's use of string formatting or with the driver-level parsing of the parameter, both of which could be demonstrated before the fix. The change only applies to anonymized parameter names that are generated and consumed internally, not end-user defined names, so the change should have no impact on any existing code. Applies in particular to the psycopg2 driver which does not otherwise quote special parameter names, but also strips leading underscores to suit Oracle (but not yet leading numbers, as some anon parameters are currently entirely numeric/underscore based); Oracle in any case continues to quote parameter names that include special characters. Fixes: #4837 Change-Id: I21cb654c3e4ef786114160b8b4295242720bf3f9
* Merge "Annotate session-bind-lookup entity in Query-produced selectables"mike bayer2019-08-301-12/+54
|\
| * Annotate session-bind-lookup entity in Query-produced selectablesMike Bayer2019-08-301-12/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | Added new entity-targeting capabilities to the :class:`.Query` object to help with the case where the :class:`.Session` is using a bind dictionary against mapped classes, rather than a single bind, and the :class:`.Query` is against a Core statement that was ultimately generated from a method such as :meth:`.Query.subquery`; a deep search is performed to locate any ORM entity related to the query in order to locate a mapper if one is not otherwise present. Fixes: #4829 Change-Id: I95cf325a5aba21baec4b313246c6f4d692284820
* | Render LIMIT/OFFSET conditions after compile on select dialectsMike Bayer2019-08-304-460/+556
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added new "post compile parameters" feature. This feature allows a :func:`.bindparam` construct to have its value rendered into the SQL string before being passed to the DBAPI driver, but after the compilation step, using the "literal render" feature of the compiler. The immediate rationale for this feature is to support LIMIT/OFFSET schemes that don't work or perform well as bound parameters handled by the database driver, while still allowing for SQLAlchemy SQL constructs to be cacheable in their compiled form. The immediate targets for the new feature are the "TOP N" clause used by SQL Server (and Sybase) which does not support a bound parameter, as well as the "ROWNUM" and optional "FIRST_ROWS()" schemes used by the Oracle dialect, the former of which has been known to perform better without bound parameters and the latter of which does not support a bound parameter. The feature builds upon the mechanisms first developed to support "expanding" parameters for IN expressions. As part of this feature, the Oracle ``use_binds_for_limits`` feature is turned on unconditionally and this flag is now deprecated. - adds limited support for "unique" bound parameters within a text() construct. - adds an additional int() check within the literal render function of the Integer datatype and tests that non-int values raise ValueError. Fixes: #4808 Change-Id: Iace97d544d1a7351ee07db970c6bc06a19c712c6
View Lorry Controller Status