summaryrefslogtreecommitdiff
path: root/test/sql
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Fix LegacyRow/Row index access"mike bayer2021-04-081-12/+117
|\
| * Fix LegacyRow/Row index accessMike Bayer2021-04-081-12/+117
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed up the behavior of the :class:`_result.Row` object when dictionary access is used upon it, meaning converting to a dict via ``dict(row)`` or accessing members using strings or other objects i.e. ``row["some_key"]`` works as it would with a dictionary, rather than raising ``TypeError`` as would be the case with a tuple, whether or not the C extensions are in place. This was originally supposed to emit a 2.0 deprecation warning for the "non-future" case using :class:`_result.LegacyRow`, and was to raise ``TypeError`` for the "future" :class:`_result.Row` class. However, the C version of :class:`_result.Row` was failing to raise this ``TypeError``, and to complicate matters, the :meth:`_orm.Session.execute` method now returns :class:`_result.Row` in all cases to maintain consistency with the ORM result case, so users who didn't have C extensions installed would see different behavior in this one case for existing pre-1.4 style code. Therefore, in order to soften the overall upgrade scheme as most users have not been exposed to the more strict behavior of :class:`_result.Row` up through 1.4.6, :class:`_result.LegacyRow` and :class:`_result.Row` both provide for string-key access as well as support for ``dict(row)``, in all cases emitting the 2.0 deprecation warning when ``SQLALCHEMY_WARN_20`` is enabled. The :class:`_result.Row` object still uses tuple-like behavior for ``__contains__``, which is probably the only noticeable behavioral change compared to :class:`_result.LegacyRow`, other than the removal of dictionary-style methods ``values()`` and ``items()``. Also remove filters for result set warnings. callcounts updated for 2.7/ 3.9, am pushing jenkins to use python 3.9 now Fixes: #6218 Change-Id: Ia69b974f3dbc46943c57423f57ec82323c8ae63b
* | Merge "Infer types in BindParameter when expanding=True"mike bayer2021-04-083-3/+60
|\ \
| * | Infer types in BindParameter when expanding=TrueMike Bayer2021-04-083-3/+60
| |/ | | | | | | | | | | | | | | | | | | | | | | | | Enhanced the "expanding" feature used for :meth:`_sql.ColumnOperators.in_` operations to infer the type of expression from the right hand list of elements, if the left hand side does not have any explicit type set up. This allows the expression to support stringification among other things. In 1.3, "expanding" was not automatically used for :meth:`_sql.ColumnOperators.in_` expressions, so in that sense this change fixes a behavioral regression. Fixes: #6222 Change-Id: Icdfda1e2c226a21896cafd6d8f251547794451c2
* | Merge "support multivalues insert on strsqlcompiler"mike bayer2021-04-071-0/+11
|\ \
| * | support multivalues insert on strsqlcompilerMike Bayer2021-04-071-0/+11
| |/ | | | | | | | | | | | | | | Fixed the "stringify" compiler to support a basic stringification of a "multirow" INSERT statement, i.e. one with multiple tuples following the VALUES keyword. Change-Id: I1fe38d204d9965275d3a72157d5a72a53bec4b11
* | Expand reg for schema translate map for most special charactersMike Bayer2021-04-071-0/+70
|/ | | | | | | | | | | | Fixed regression where usage of a token in the :paramref:`_engine.Connection.execution_options.schema_translate_map` dictionary which contained special characters such as braces would fail to be substituted properly. Use of square bracket characters ``[]`` is now explicitly disallowed as these are used as a delimiter character in the current implementation. Fixes: #6216 Change-Id: I7ccfc2292b17340054cedf485ed1adf3119b96c8
* Merge "Table arguments name and metadata are positional only"mike bayer2021-04-061-0/+15
|\
| * Table arguments name and metadata are positional onlyFederico Caselli2021-04-061-0/+15
| | | | | | | | | | | | | | | | | | | | | | The :class:`_sql.Table` object now raises an informative error message if it is instantiated without passing at least the :paramref:`_sql.Table.name` and :paramref:`_sql.Table.metadata` arguments positionally. Previously, if these were passed as keyword arguments, the object would silently fail to initialize correctly. Fixes: #6135 Change-Id: I54d0c89fd549fc504289a87ea0bb37369f982b06
* | Merge "Disallow AliasedReturnsRows from execution"mike bayer2021-04-063-23/+11
|\ \
| * | Disallow AliasedReturnsRows from executionMike Bayer2021-04-053-23/+11
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Executing a :class:`_sql.Subquery` using :meth:`_engine.Connection.execute` is deprecated and will emit a deprecation warning; this use case was an oversight that should have been removed from 1.4. The operation will now execute the underlying :class:`_sql.Select` object directly for backwards compatibility. Similarly, the :class:`_sql.CTE` class is also not appropriate for execution. In 1.3, attempting to execute a CTE would result in an invalid "blank" SQL statement being executed; since this use case was not working it now raises :class:`_exc.ObjectNotExecutableError`. Previously, 1.4 was attempting to execute the CTE as a statement however it was working only erratically. The change also breaks out StatementRole from ReturnsRowsRole, as these roles should not be in the same lineage (some statements don't return rows, the whole class of ReturnsRows that are from clauses are not statements). Consolidate StatementRole and CoerceTextStatementRole as there's no usage difference between these. Simplify some old tests that were trying to make sure that "execution options" didn't transmit from a cte/subquery out to a select; as cte/subuqery() aren't executable in any case the options are removed. Fixes: #6204 Change-Id: I62613b7ab418afdd22c409eae75659e3f52fb65f
* | uniquify when popping literal_execute_params from param dictMike Bayer2021-04-051-0/+85
|/ | | | | | | | | | | Fixed further issues in the same area as that of :ticket:`6173` released in 1.4.5, where a "postcompile" parameter, again most typically those used for LIMIT/OFFSET rendering in Oracle and SQL Server, would fail to be processed correctly if the same parameter rendered in multiple places in the statement. Fixes: #6202 Change-Id: I95c355aa52a7546fe579ad67f9a8402a213cb79d
* Ensure Grouping._with_binary_element_type() maintains classMike Bayer2021-04-022-0/+30
| | | | | | | | | | Fixed regression where use of the :meth:`.Operators.in_` method with a :class:`_sql.Select` object against a non-table-bound column would produce an ``AttributeError``, or more generally using a :class:`_sql.ScalarSelect` that has no datatype in a binary expression would produce invalid state. Fixes: #6181 Change-Id: I1ddea433b3603fdab8f489bff571b512a6ffc66b
* Merge "Add ``omit_aliases`` in ``Enum``."mike bayer2021-04-021-9/+61
|\
| * Add ``omit_aliases`` in ``Enum``.Federico Caselli2021-04-011-9/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new parameter :paramref:`_types.Enum.omit_aliases` in :class:`_types.Enum` type allow filtering aliases when using a pep435 Enum. Previous versions of SQLAlchemy kept aliases in all cases, creating database enum type with additional states, meaning that they were treated as different values in the db. For backward compatibility this flag defaults to ``False`` in the 1.4 series, but will be switched to ``True`` in a future version. A deprecation warning is raise if this flag is not specified and the passed enum contains aliases. Fixes: #6146 Change-Id: I547322ffa90d0273d91bb3bf8bfea6ec934d48b9
* | Merge "Apply quoting to render_derived() names"mike bayer2021-04-011-0/+22
|\ \
| * | Apply quoting to render_derived() namesMike Bayer2021-04-011-0/+22
| |/ | | | | | | | | | | | | | | | | | | Fixed bug in new :meth:`_functions.FunctionElement.render_derived` feature where column names rendered out explicitly in the alias SQL would not have proper quoting applied for case sensitive names and other non-alphanumeric names. Fixes: #6183 Change-Id: I33e2534affc6e1f449f564750028fd027cb0f352
* | Correct for Variant + ARRAY cases in psycopg2Mike Bayer2021-04-011-0/+6
|/ | | | | | | | | | | | | | Fixed regression caused by :ticket:`6023` where the PostgreSQL cast operator applied to elements within an :class:`_types.ARRAY` when using psycopg2 would fail to use the correct type in the case that the datatype were also embedded within an instance of the :class:`_types.Variant` adapter. Additionally, repairs support for the correct CREATE TYPE to be emitted when using a ``Variant(ARRAY(some_schema_type))``. Fixes: #6182 Change-Id: I1b9ba7c876980d4650715a0b0801b46bdc72860d
* Correct for CTE correspondence w/ aliased CTEMike Bayer2021-03-311-0/+40
| | | | | | | | | Fixed regression where the :func:`_orm.joinedload` loader strategy would not successfully joinedload to a mapper that is mapper against a :class:`.CTE` construct. Fixes: #6172 Change-Id: I667e46d00d4209dab5a89171118a00a7c30fb542
* Merge "Repair exception handling in CursorResult"mike bayer2021-03-311-0/+31
|\
| * Repair exception handling in CursorResultFederico Caselli2021-03-301-0/+31
| | | | | | | | | | Fixes: #6138 Change-Id: I794a3da688fd8577fb06770ef02bf827a5c55397
* | TypeDecorator passes "outer" flag to itself for set_parent accountingMike Bayer2021-03-302-25/+24
|/ | | | | | | | | | | | | | Fixed bug first introduced in as some combination of :ticket:`2892`, :ticket:`2919` nnd :ticket:`3832` where the attachment events for a :class:`_types.TypeDecorator` would be doubled up against the "impl" class, if the "impl" were also a :class:`_types.SchemaType`. The real-world case is any :class:`_types.TypeDecorator` against :class:`_types.Enum` or :class:`_types.Boolean` would get a doubled :class:`_schema.CheckConstraint` when the ``create_constraint=True`` flag is set. Fixes: #6152 Change-Id: I3218b7081297270c132421f6765b5c3673d10a5c
* Merge "Allow dropping a schema with a sequence shared by more than one table."mike bayer2021-03-251-9/+58
|\
| * Allow dropping a schema with a sequence shared by more than one table.Federico Caselli2021-03-201-9/+58
| | | | | | | | | | Fixes: #6071 Change-Id: I5c4483abf075622cccb73cb4c4f8c873174b4e32
* | Accept **kw in annotated._clone() methodMike Bayer2021-03-251-0/+11
| | | | | | | | | | | | | | | | | | | | Fixed bug where combinations of the new "relationship with criteria" feature could fail in conjunction with features that make use of the new "lambda SQL" feature, including loader strategies such as selectinload and lazyload, for more complicated scenarios such as polymorphic loading. Fixes: #6131 Change-Id: I915dead6596866ae5fd1a7f593a90bce4b61d1af
* | Adjust derivation rules for table vs. subquery against a joinMike Bayer2021-03-231-14/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed bug where ORM queries using a correlated subquery in conjunction with :func:`_orm.column_property` would fail to correlate correctly to an enclosing subquery or to a CTE when :meth:`_sql.Select.correlate_except` were used in the property to control correlation, in cases where the subquery contained the same selectables as ones within the correlated subquery that were intended to not be correlated. This is achieved by adding a limiting factor to ClauseAdapter which is to explicitly pass the selectables we will be adapting "from", which is then used by AliasedClass to limit "from" to the mappers represented by the AliasedClass. This did cause one test where an alias for a contains_eager() was missing to suddenly fail, and the test was corrected, however there may be some very edge cases like that one where the tighter criteria causes an existing use case that's relying on the more liberal aliasing to require modifications. Fixes: #6060 Change-Id: I8342042641886e1a220beafeb94fe45ea7aadb33
* | Use tuple for function package namesMike Bayer2021-03-191-0/+6
| | | | | | | | | | | | | | | | | | Fixed issue where using a ``func`` that includes dotted packagenames would fail to be cacheable by the SQL caching system due to a Python list of names that needed to be a tuple. Fixes: #6101 Change-Id: I1d4bb5bf230b83596c59b6a04aa498f18ecd9613
* | Correct for coercion from list args to positional for caseMike Bayer2021-03-191-0/+47
| | | | | | | | | | | | | | | | | | Fixed regression in the :func:`_sql.case` construct, where the "dictionary" form of argument specification failed to work correctly if it were passed positionally, rather than as a "whens" keyword argument. Fixes: #6097 Change-Id: I4138f54309a08c8e4e63cfafc211176e0b9a76c7
* | Merge "Deannoate functions before matching .__class__"mike bayer2021-03-191-0/+7
|\ \
| * | Deannoate functions before matching .__class__Mike Bayer2021-03-191-0/+7
| |/ | | | | | | | | | | | | | | | | | | Fixed regression where the SQL compilation of a :class:`.Function` would not work correctly if the object had been "annotated", which is an internal memoization process used mostly by the ORM. In particular it could affect ORM lazy loads which make greater use of this feature in 1.4. Fixes: #6095 Change-Id: I7a6527df651f440a04d911ba78ee0b0dd4436dcd
* | Ensure ClauseAdapter treats FunctionElement as a ColumnElementMike Bayer2021-03-181-0/+34
|/ | | | | | | | | | Fixed regression where use of an unnamed SQL expression such as a SQL function would raise a column targeting error if the query itself were using joinedload for an entity and was also being wrapped in a subquery by the joinedload eager loading process. Fixes: #6086 Change-Id: I22cf4d6974685267c4f903bd7639be8271c6c1ef
* Raise at Core / ORM concrete inh level for label overlapMike Bayer2021-03-181-0/+31
| | | | | | | | | | | | | | | | | | | Fixed regression where the :class:`.ConcreteBase` would fail to map at all when a mapped column name overlapped with the discriminator column name, producing an assertion error. The use case here did not function correctly in 1.3 as the polymorphic union would produce a query that ignored the discriminator column entirely, while emitting duplicate column warnings. As 1.4's architecture cannot easily reproduce this essentially broken behavior of 1.3 at the ``select()`` level right now, the use case now raises an informative error message instructing the user to use the ``.ConcreteBase._concrete_discriminator_name`` attribute to resolve the conflict. To assist with this configuration, ``.ConcreteBase._concrete_discriminator_name`` may be placed on the base class only where it will be automatically used by subclasses; previously this was not the case. Fixes: #6090 Change-Id: I8b7d01e4c9ea0dc97f30b8cd658b3505b24312a7
* Merge "Use explicit names for mapper _get_clause parameters"mike bayer2021-03-171-0/+24
|\
| * Use explicit names for mapper _get_clause parametersMike Bayer2021-03-171-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed a critical regression in the relationship lazy loader where the SQL criteria used to fetch a related many-to-one object could go stale in relation to other memoized structures within the loader if the mapper had configuration changes, such as can occur when mappers are late configured or configured on demand, producing a comparison to None and returning no object. Huge thanks to Alan Hamlett for their help tracking this down late into the night. The primary change is that mapper._get_clause() uses a fixed name for its bound parameters, which is memoized under a lambda statement in the case of many-to-one lazy loading. This has implications for some other logic namely the .compare() used by loader strategies to determine use_get needed to be adjusted. This change also repairs the lambda module's behavior of removing the "required" flag from bound parameters, which caused this issue to also fail silently rather than issuing an error for a required bind parameter. Fixes: #6055 Change-Id: I19e1aba9207a049873e0f13c19bad7541e223cfd
* | Provide special row proxies for count and indexMike Bayer2021-03-171-0/+43
|/ | | | | | | | | | | | | The Python ``namedtuple()`` has the behavior such that the names ``count`` and ``index`` will be served as tuple values if the named tuple includes those names; if they are absent, then their behavior as methods of ``collections.abc.Sequence`` is maintained. Therefore the :class:`_result.Row` and :class:`_result.LegacyRow` classes have been fixed so that they work in this same way, maintaining the expected behavior for database rows that have columns named "index" or "count". Fixes: #6074 Change-Id: I49a093da02f33f231d22ed5999c09fcaa3a68601
* CAST the elements in ARRAYs when using psycopg2Federico Caselli2021-03-151-16/+4
| | | | | | | | | | | | Adjusted the psycopg2 dialect to emit an explicit PostgreSQL-style cast for bound parameters that contain ARRAY elements. This allows the full range of datatypes to function correctly within arrays. The asyncpg dialect already generated these internal casts in the final statement. This also includes support for array slice updates as well as the PostgreSQL-specific :meth:`_postgresql.ARRAY.contains` method. Fixes: #6023 Change-Id: Ia7519ac4371a635f05ac69a3a4d0f4e6d2f04cad
* Apply percent sign escaping to op(), custom_op()Mike Bayer2021-03-092-28/+100
| | | | | | | | | | | Fixed bug where the "percent escaping" feature that occurs with dialects that use the "format" or "pyformat" bound parameter styles was not enabled for the :meth:`.Operations.op` and :meth:`.Operations.custom_op` methods, for custom operators that use percent signs. The percent sign will now be automatically doubled based on the paramstyle as necessary. Fixes: #6016 Change-Id: I285c5fc082481c2ee989edf1b02a83a6087ea26a
* Merge "Fix named CHECK constraint name omitted on repeated creates"mike bayer2021-03-071-24/+20
|\
| * Fix named CHECK constraint name omitted on repeated createsGord Thompson2021-03-061-24/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue where the CHECK constraint generated by :class:`_types.Boolean` or :class:`_types.Enum` would fail to render the naming convention correctly after the first compilation, due to an unintended change of state within the name given to the constraint. This issue was first introduced in 0.9 in the fix for issue #3067, and the fix revises the approach taken at that time which appears to have been more involved than what was needed. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Fixes: #6007 Change-Id: I7ecff0a9d86191520f6841b3922a5af5a6971fba
* | improve targeting and labeling for unary() in columns clauseMike Bayer2021-03-061-0/+17
|/ | | | | | | | | | | | | | | | | | | | | | Fixed regression where usage of the standalone :func:`_sql.distinct()` used in the form of being directly SELECTed would fail to be locatable in the result set by column identity, which is how the ORM locates columns. While standalone :func:`_sql.distinct()` is not oriented towards being directly SELECTed (use :meth:`_sql.select.distinct` for a regular ``SELECT DISTINCT..``) , it was usable to a limited extent in this way previously (but wouldn't work in subqueries, for example). The column targeting for unary expressions such as "DISTINCT <col>" has been improved so that this case works again, and an additional improvement has been made so that usage of this form in a subquery at least generates valid SQL which was not the case previously. The change additionally enhances the ability to target elements in ``row._mapping`` based on SQL expression objects in ORM-enabled SELECT statements, including whether the statement was invoked by ``connection.execute()`` or ``session.execute()``. Fixes: #6008 Change-Id: I5cfa39435f5418861d70a7db8f52ab4ced6a792e
* Merge "support stringify for plain CTE"mike bayer2021-02-281-0/+11
|\
| * support stringify for plain CTEMike Bayer2021-02-271-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Altered the compilation for the :class:`.CTE` construct so that a string is returned representing the inner SELECT statement if the :class:`.CTE` is stringified directly, outside of the context of an enclosing SELECT; This is the same behavior of :meth:`_FromClause.alias` and :meth:`_SelectStatement.subquery`. Previously, a blank string would be returned as the CTE is normally placed above a SELECT after that SELECT has been generated, which is generally misleading when debugging. Change-Id: Id3007c28e4a7a56d867e850bb890752946bd8f6f References: #5988
* | implement visit_unsupported_compilation for TypeCompilerMike Bayer2021-02-251-0/+14
|/ | | | | | | | Fixed regression where the "unsupported compilation error" for unknown datatypes would fail to raise correctly. Fixes: #5979 Change-Id: I984fe95666813832ab5bdfc568322e2aa7cc3db0
* Merge "Deprecate and rename schema .copy() methods"mike bayer2021-02-191-15/+15
|\
| * Deprecate and rename schema .copy() methodsGord Thompson2021-02-181-15/+15
| | | | | | | | | | Fixes: #5953 Change-Id: I1e69a1628e408f06b43efbc0cc52fc0ad1e8cbc4
* | Extract table names when comparing to nrte errorMike Bayer2021-02-181-0/+49
|/ | | | | | | | | | | | Fixed issue where the process of joining two tables could fail if one of the tables had an unrelated, unresolvable foreign key constraint which would raise :class:`_exc.NoReferenceError` within the join process, which nonetheless could be bypassed to allow the join to complete. The logic which tested the exception for signficance within the process would make assumptions about the construct which would fail. Fixes: #5952 Change-Id: I492dacd082ddcf8abb1310ed447a6ed734595bb7
* Support legacy select(<iterable>) in addition to select(<list>) in v1.4Oliver Rice2021-02-151-0/+10
| | | | | | | | | | | | | | | Fixed regression where use of an arbitrary iterable with the :func:`_sql.select` function was not working, outside of plain lists. The forwards/backwards compatibility logic here now checks for a wider range of incoming "iterable" types including that a ``.c`` collection from a selectable can be passed directly. Pull request compliments of Oliver Rice. Fixes: #5935 Closes: #5936 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5936 Pull-request-sha: 575ab3e7df30fc8da03752d102c8eeb6cb3a3e3d Change-Id: Icd972f1078d9ea96c47a64133079f00d9b0a66f3
* Further refine labeling for renamed columnsMike Bayer2021-02-122-6/+7
| | | | | | | | | | | | | | | Forked from I22f6cf0f0b3360e55299cdcb2452cead2b2458ea we are attempting to decide the case for columns mapped under a different name. since the .key feature of Column seems to support this fully, see if an annotation can be used to indicate an effective .key for a column. The effective change is that the labeling of column expressions in rows has been improved to retain the original name of the ORM attribute even if used in a subquery. References: #5933 Change-Id: If251f556f7d723f50d349f765f1690d6c679d2ef
* Merge "Apply consistent labeling for all future style ORM queries"mike bayer2021-02-122-0/+41
|\
| * Apply consistent labeling for all future style ORM queriesMike Bayer2021-02-112-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed issue in new 1.4/2.0 style ORM queries where a statement-level label style would not be preserved in the keys used by result rows; this has been applied to all combinations of Core/ORM columns / session vs. connection etc. so that the linkage from statement to result row is the same in all cases. also repairs a cache key bug where query.from_statement() vs. select().from_statement() would not be disambiguated; the compile options were not included in the cache key for FromStatement. Fixes: #5933 Change-Id: I22f6cf0f0b3360e55299cdcb2452cead2b2458ea
View Lorry Controller Status