summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql
Commit message (Collapse)AuthorAgeFilesLines
...
* | Added back ``items`` and ``values`` to ``ColumnCollection`` class.Federico Caselli2021-03-171-0/+6
| | | | | | | | | | Fixes: #6068 Change-Id: Idb42c864e17c02d7b89cffa667dcf853ec93e5c2
* | Merge "turn off eager configure_mappers() outside of Query, Load"mike bayer2021-03-161-2/+10
|\ \ | |/ |/|
| * turn off eager configure_mappers() outside of Query, LoadMike Bayer2021-03-161-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where producing a Core expression construct such as :func:`_sql.select` using ORM entities would eagerly configure the mappers, in an effort to maintain compatibility with the :class:`_orm.Query` object which necessarily does this to support many backref-related legacy cases. However, core :func:`_sql.select` constructs are also used in mapper configurations and such, and to that degree this eager configuration is more of an inconvenience, so eager configure has been disabled for the :func:`_sql.select` and other Core constructs in the absence of ORM loading types of functions such as :class:`_orm.Load`. The change maintains the behavior of :class:`_orm.Query` so that backwards compatibility is maintained. However, when using a :func:`_sql.select` in conjunction with ORM entities, a "backref" that isn't explicitly placed on one of the classes until mapper configure time won't be available unless :func:`_orm.configure_mappers` or the newer :func:`_orm.registry.configure` has been called elsewhere. Prefer using :paramref:`_orm.relationship.back_populates` for more explicit relationship configuration which does not have the eager configure requirement. Fixes: #6066 Change-Id: I7a953ddcc189471fbac63c97c51ab8956f64012e
* | CAST the elements in ARRAYs when using psycopg2Federico Caselli2021-03-153-0/+12
|/ | | | | | | | | | | | 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-091-3/+5
| | | | | | | | | | | 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 "Ignore flake8 F401 on specific files"mike bayer2021-03-072-179/+179
|\
| * Ignore flake8 F401 on specific filesFederico Caselli2021-03-032-179/+179
| | | | | | | | | | | | | | | | Uses the flake8 option per-file-ignores that was introduced in a recent version of flake8 (3.7.+) to avoid having lots of "noqa" in import only files Change-Id: Ib4871d63bad7e578165615df139cbf6093479201
* | Merge "Fix named CHECK constraint name omitted on repeated creates"mike bayer2021-03-074-41/+12
|\ \
| * | Fix named CHECK constraint name omitted on repeated createsGord Thompson2021-03-064-41/+12
| |/ | | | | | | | | | | | | | | | | | | | | | | | | 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-30/+10
|/ | | | | | | | | | | | | | | | | | | | | | 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-5/+16
|\
| * support stringify for plain CTEMike Bayer2021-02-271-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | 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/+6
|/ | | | | | | | 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-6/+70
|\
| * Deprecate and rename schema .copy() methodsGord Thompson2021-02-181-6/+70
| | | | | | | | | | Fixes: #5953 Change-Id: I1e69a1628e408f06b43efbc0cc52fc0ad1e8cbc4
* | Extract table names when comparing to nrte errorMike Bayer2021-02-181-2/+7
|/ | | | | | | | | | | | 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
* Merge "Support legacy select(<iterable>) in addition to select(<list>) in v1.4"mike bayer2021-02-151-1/+5
|\
| * Support legacy select(<iterable>) in addition to select(<list>) in v1.4Oliver Rice2021-02-151-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | Accept ColumnCollection in update_on_conflict(set_=Gord Thompson2021-02-151-1/+1
| | | | | | | | | | Fixes: #5939 Change-Id: I21d7125765028e2a98d5ef4c32d8e7e457aa2d12
* | Merge "Allow update.returing() to work with from_statement()"mike bayer2021-02-141-1/+7
|\ \ | |/ |/|
| * Allow update.returing() to work with from_statement()Mike Bayer2021-02-141-1/+7
| | | | | | | | | | | | | | | | | | | | The ORM used in :term:`2.0 style` can now return ORM objects from the rows returned by an UPDATE..RETURNING or INSERT..RETURNING statement, by supplying the construct to :meth:`_sql.Select.from_statement` in an ORM context. Change-Id: I59c9754ff1cb3184580dd5194ecd2971d4e7f8e8 References: #5940
* | expand and further generalize bound parameter translateMike Bayer2021-02-141-0/+18
|/ | | | | | | | | | | | | | | | | | | | Continued with the improvement made as part of :ticket:`5653` to further support bound parameter names, including those generated against column names, for names that include colons, parenthesis, and question marks, as well as improved test support, so that bound parameter names even if they are auto-derived from column names should have no problem including for parenthesis in psycopg2's "pyformat" style. As part of this change, the format used by the asyncpg DBAPI adapter (which is local to SQLAlchemy's asyncpg diaelct) has been changed from using "qmark" paramstyle to "format", as there is a standard and internally supported SQL string escaping style for names that use percent signs with "format" style (i.e. to double percent signs), as opposed to names that use question marks with "qmark" style (where an escaping system is not defined by pep-249 or Python). Fixes: #5941 Change-Id: Id86f5af81903d7063a8e3505e60df56490f85358
* Further refine labeling for renamed columnsMike Bayer2021-02-123-32/+50
| | | | | | | | | | | | | | | 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-60/+90
|\
| * Apply consistent labeling for all future style ORM queriesMike Bayer2021-02-112-60/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | test Function(?:Element)._bind_param() with in_()Mike Bayer2021-02-111-2/+4
|/ | | | | | | | Fixed 1.4 regression where the :meth:`_functions.Function.in_` method was not covered by tests and failed to function properly in all cases. Fixes: #5934 Change-Id: I93423a296e391aabd5594cb670d36b91ced0231d
* Track a second from_linter for lateral subqueriesMike Bayer2021-02-051-5/+37
| | | | | | | | | | | | | | | Fixed bug where the "cartesian product" assertion was not correctly accommodating for joins between tables that relied upon the use of LATERAL to connect from a subquery to another subquery in the enclosing context. Additionally, enabled from_linting for the base assert_compile(), however it remains off by default; to enable by default we would have to make sure it isn't set for DDL compiles and there's also a lot of tests that would also need to turn it off, so leaving this off for expediency. Fixes: #5924 Change-Id: I22604baf572f8c4d96befcc610b3dcb79c13fc4a
* Accommodate column-based naming conventions for pk constraintMike Bayer2021-02-043-11/+47
| | | | | | | | | | | | | | Repaired / implemented support for primary key constraint naming conventions that use column names/keys/etc as part of the convention. In particular, this includes that the :class:`.PrimaryKeyConstraint` object that's automatically associated with a :class:`.schema.Table` will update its name as new primary key :class:`_schema.Column` objects are added to the table and then to the constraint. Internal failure modes related to this constraint construction process including no columns present, no name present or blank name present are now accommodated. Fixes: #5919 Change-Id: Ic2800b50f4a4cd5978bec48cefea0a2e198e0123
* Merge "Implement support for functions as FROM with columns clause support"mike bayer2021-02-0312-128/+785
|\
| * Implement support for functions as FROM with columns clause supportMike Bayer2021-02-0312-128/+785
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implemented support for "table valued functions" along with additional syntaxes supported by PostgreSQL, one of the most commonly requested features. Table valued functions are SQL functions that return lists of values or rows, and are prevalent in PostgreSQL in the area of JSON functions, where the "table value" is commonly referred towards as the "record" datatype. Table valued functions are also supported by Oracle and SQL Server. Moved from I5b093b72533ef695293e737eb75850b9713e5e03 due to accidental push Fixes: #3566 Change-Id: Iea36d04c80a5ed3509dcdd9ebf0701687143fef5
* | Add coercions to literal()Mike Bayer2021-02-033-4/+25
|/ | | | | | | | | | To prevent literal() from receiving a ClauseElement which then leads to confusing results, add a new LiteralValueRole coercion that does an _is_literal() check and implement for literal(). Fixes: #5639 Change-Id: Ibd686544af2d7c013765278f984baf237de88caf
* set identifier length for MySQL constraints to 64Mike Bayer2021-01-301-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | The rule to limit index names to 64 also applies to all DDL names, such as those coming from naming conventions. Add another limiting variable for constraint names and create test cases against all constraint types. Additionally, codified in the test suite MySQL's lack of support for naming of a FOREIGN KEY constraint after the name was given, which apparently assigns the name to an associated KEY but not the constraint itself, until MySQL 8 and MariaDB 10.5 which appear to have resolved the behavior. However it's not clear how Alembic hasn't had issues reported with this so far. Fixed long-lived bug in MySQL dialect where the maximum identifier length of 255 was too long for names of all types of constraints, not just indexes, all of which have a size limit of 64. As metadata naming conventions can create too-long names in this area, apply the limit to the identifier generator within the DDL compiler. Fixes: #5898 Change-Id: I79549474845dc29922275cf13321c07598dcea08
* Merge "Use schema._copy_expression() fully in column collection constraints"mike bayer2021-01-291-7/+17
|\
| * Use schema._copy_expression() fully in column collection constraintsGord Thompson2021-01-291-7/+17
| | | | | | | | | | | | | | | | | | | | Fixed issue where using :meth:`_schema.Table.to_metadata` (called :meth:`_schema.Table.tometadata` in 1.3) in conjunction with a PostgreSQL :class:`_postgresql.ExcludeConstraint` that made use of ad-hoc column expressions would fail to copy correctly. Fixes: #5850 Change-Id: I062480afb23f6f60962b7b55bc93f5e4e6ff05e4
* | Clarify Column.index / Column.unique parametersMike Bayer2021-01-291-12/+95
|/ | | | | | | | | | These parameters need to be more clear that they cause a constraint / index object to be generated. Clarify the rules by which this occurs and include contextual information about naming conventions as well. Change-Id: I8dc96ead4457215abed391fd1b9f732a1eef6e09 References: #5887
* Render NULL for bindparam w/ None value/literal_binds, warnMike Bayer2021-01-281-4/+10
| | | | | | | | | | | | | | | | | Adjusted the "literal_binds" feature of :class:`_sql.Compiler` to render NULL for a bound parameter that has ``None`` as the value, either explicitly passed or omitted. The previous error message "bind parameter without a renderable value" is removed, and a missing or ``None`` value will now render NULL in all cases. Previously, rendering of NULL was starting to happen for DML statements due to internal refactorings, but was not explicitly part of test coverage, which it now is. While no error is raised, when the context is within that of a column comparison, and the operator is not "IS"/"IS NOT", a warning is emitted that this is not generally useful from a SQL perspective. Fixes: #5888 Change-Id: Id5939d8dbfb1156a9f8a7f7e76cf18327155331a
* Merge "Fix many spell glitches in docstrings and comments"mike bayer2021-01-269-19/+19
|\
| * Fix many spell glitches in docstrings and commentsLele Gaifax2021-01-249-20/+20
| | | | | | | | | | | | | | | | | | | | These were revealed by running `pylint --disable all --enable spelling --spelling-dict en_US` over all sources. Closes: #5868 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5868 Pull-request-sha: bb249195d92e3b806e81ecf1192d5a1b3cd5db48 Change-Id: I96080ec93a9fbd20ce21e9e16265b3c77f22bb14
* | Replace with_labels() and apply_labels() in ORM/CoreGord Thompson2021-01-264-33/+191
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace :meth:`_orm.Query.with_labels` and :meth:`_sql.GenerativeSelect.apply_labels` with explicit getters and setters ``get_label_style`` and ``set_label_style`` to accommodate the three supported label styles: ``LABEL_STYLE_DISAMBIGUATE_ONLY`` (default), ``LABEL_STYLE_TABLENAME_PLUS_COL``, and ``LABEL_STYLE_NONE``. In addition, for Core and "future style" ORM queries, ``LABEL_STYLE_DISAMBIGUATE_ONLY`` is now the default label style. This style differs from the existing "no labels" style in that labeling is applied in the case of column name conflicts; with ``LABEL_STYLE_NONE``, a duplicate column name is not accessible via name in any case. For legacy ORM queries using :class:`_query.Query`, the table-plus-column names labeling style applied by ``LABEL_STYLE_TABLENAME_PLUS_COL`` continues to be used so that existing test suites and logging facilities see no change in behavior by default, however this style of labeling is no longer required for SQLAlchemy queries to function, as result sets are commonly matched to columns using a positional approach since SQLAlchemy 1.0. Within test suites, all use of apply_labels() / use_labels now uses the new methods. New tests added to test/sql/test_deprecations.py nad test/orm/test_deprecations.py to cover just the old apply_labels() method call. Tests in ORM that made explicit use apply_labels()/ etc. where it isn't needed for the ORM to work correctly use default label style now. Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Fixes: #4757 Change-Id: I5fdcd2ed4ae8c7fe62f8be2b6d0e8f66409b6a54
* Revert "Implement support for functions as FROM with columns clause support"Mike Bayer2021-01-217-514/+75
| | | | | | | This reverts commit 05a31f2708590161d4b3b4c7ff65196c99b4a22b. Atom has this little button called "push" and just pushes to master, I wasn't even *on* master. oops
* Implement support for functions as FROM with columns clause supportMike Bayer2021-01-207-75/+514
| | | | | | | WIP Fixes: #3566 Change-Id: I5b093b72533ef695293e737eb75850b9713e5e03
* chain joins from SelectState context, not SelectMike Bayer2021-01-201-1/+14
| | | | | | | | | | | | | Fixed issue in new :meth:`_sql.Select.join` method where chaining from the current JOIN wasn't looking at the right state, causing an expression like "FROM a JOIN b <onclause>, b JOIN c <onclause>" rather than "FROM a JOIN b <onclause> JOIN c <onclause>". Added :meth:`_sql.Select.outerjoin_from` method to complement :meth:`_sql.Select.join_from`. Fixes: #5858 Change-Id: I1346ebe0963bbd1e4bf868650e3ee1d6d3072f04
* Document Table/Column accessorsMike Bayer2021-01-192-2/+112
| | | | | | | | | | | | | As Sphinx will not allow us to add attributes to the .rst file while maintaining order, these have to be added as class-level attributes. Inlcude notes that "index" and "unique" parameters, while indicated by Column.index / Column.unique, do not actually indicate if the column is part of an index. Fixes: #5851 Change-Id: I18fbaf6c504c4b1005b4c51057f80397fb48b387
* Merge "``Identity`` implies ``nullable=False``."mike bayer2021-01-172-16/+45
|\
| * ``Identity`` implies ``nullable=False``.Federico Caselli2021-01-162-16/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Altered the behavior of the :class:`_schema.Identity` construct such that when applied to a :class:`_schema.Column`, it will automatically imply that the value of :paramref:`_sql.Column.nullable` should default to ``False``, in a similar manner as when the :paramref:`_sql.Column.primary_key` parameter is set to ``True``. This matches the default behavior of all supporting databases where ``IDENTITY`` implies ``NOT NULL``. The PostgreSQL backend is the only one that supports adding ``NULL`` to an ``IDENTITY`` column, which is here supported by passing a ``True`` value for the :paramref:`_sql.Column.nullable` parameter at the same time. Fixes: #5775 Change-Id: I0516d506ff327cff35cda605e8897a27440e0373
* | introduce generalized decorator to prevent invalid method callsMike Bayer2021-01-162-13/+42
|/ | | | | | | | | | | | | | | | | | | This introduces the ``_exclusive_against()`` utility decorator that can be used to prevent repeated invocations of methods that typically should only be called once. An informative error message is now raised for a selected set of DML methods (currently all part of :class:`_dml.Insert` constructs) if they are called a second time, which would implicitly cancel out the previous setting. The methods altered include: :class:`_sqlite.Insert.on_conflict_do_update`, :class:`_sqlite.Insert.on_conflict_do_nothing` (SQLite), :class:`_postgresql.Insert.on_conflict_do_update`, :class:`_postgresql.Insert.on_conflict_do_nothing` (PostgreSQL), :class:`_mysql.Insert.on_duplicate_key_update` (MySQL) Fixes: #5169 Change-Id: I9278fa87cd3470dcf296ff96bb0fb17a3236d49d
* allow Executable to be accepted by Session.execute()Mike Bayer2021-01-142-2/+1
| | | | | | | | | | | | Fixed an issue where the API to create a custom executable SQL construct using the ``sqlalchemy.ext.compiles`` extension according to the documentation that's been up for many years would no longer function if only ``Executable, ClauseElement`` were used as the base classes, additional classes were needed if wanting to use :meth:`_orm.Session.execute`. This has been resolved so that those extra classes aren't needed. Change-Id: I99b8acd88515c2a52842d62974199121e64c0381
* Merge "Remove special rule for TypeDecorator of TypeDecorator"mike bayer2021-01-071-5/+1
|\
| * Remove special rule for TypeDecorator of TypeDecoratorMike Bayer2021-01-051-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Removing this check for "TypeDecorator" in impl seems to not break anything and allows TypeDecorator.with_variant() to work correctly. The line has been traced back to 2007 and does not appear to have relevance today. Fixed bug where making use of the :meth:`.TypeEngine.with_variant` method on a :class:`.TypeDecorator` type would fail to take into account the dialect-specific mappings in use, due to a rule in :class:`.TypeDecorator` that was instead attempting to check for chains of :class:`.TypeDecorator` instances. Fixes: #5816 Change-Id: Ic86d9d985810e3050f15972b4841108acca2fa3e
* | remove more bound metadataMike Bayer2021-01-051-3/+6
|/ | | | | | | | | | | | | | in Iae6ab95938a7e92b6d42086aec534af27b5577d3 I missed that the "bind" was being stuck onto the MetaData in TablesTest, which led thousands of ORM tests to still use bound metadata. Keep looking for bound metadata. standardize all ORM tests on a single means of getting a Session when the Session API isn't the thing we are directly testing, using a new function fixture_session() that replaces create_session() and uses modern defaults. Change-Id: Iaf71206e9ee568151496d8bc213a069504bf65ef
View Lorry Controller Status