summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql/compiler.py
Commit message (Collapse)AuthorAgeFilesLines
* Replace all http:// links to https://Federico Caselli2021-07-041-1/+1
| | | | | | Also replace http://pypi.python.org/pypi with https://pypi.org/project Change-Id: I84b5005c39969a82140706472989f2a30b0c7685
* Ensure compiler uses quote_schema hook for translates rendersMike Bayer2021-06-301-1/+1
| | | | | | | | | Fixed regression where the special dotted-schema name handling for the SQL Server dialect would not function correctly if the dotted schema name were used within the ``schema_translate_map`` feature. Fixes: #6697 Change-Id: Idb610755cbf8122e71223d5dd0a17fcb61b1b98d
* consider "*" col as textual orderedMike Bayer2021-06-231-1/+1
| | | | | | | | | Fixed old issue where a :func:`_sql.select()` made against the token "*", which then yielded exactly one column, would fail to correctly organize the ``cursor.description`` column name into the keys of the result object. Fixes: #6665 Change-Id: Ie8c00f62998972ad4a19a750d2642d00fde006f6
* Export deferred columns but not col props; fix CTE labelingMike Bayer2021-06-221-3/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refined the behavior of ORM subquery rendering with regards to deferred columns and column properties to be more compatible with that of 1.3 while also providing for 1.4's newer features. As a subquery in 1.4 does not make use of loader options, including :func:`_orm.deferred`, a subquery that is against an ORM entity with deferred attributes will now render those deferred attributes that refer directly to mapped table columns, as these are needed in the outer SELECT if that outer SELECT makes use of these columns; however a deferred attribute that refers to a composed SQL expression as we normally do with :func:`_orm.column_property` will not be part of the subquery, as these can be selected explicitly if needed in the subquery. If the entity is being SELECTed from this subquery, the column expression can still render on "the outside" in terms of the derived subquery columns. This produces essentially the same behavior as when working with 1.3. However in this case the fix has to also make sure that the ``.selected_columns`` collection of an ORM-enabled :func:`_sql.select` also follows these rules, which in particular allows recursive CTEs to render correctly in this scenario, which were previously failing to render correctly due to this issue. As part of this change the _exported_columns_iterator() method has been removed and logic simplified to use ._all_selected_columns from any SelectBase object where _exported_columns_iterator() was used before. Additionally sets up UpdateBase to include ReturnsRows in its hierarchy; the literal point of ReturnsRows was to be a common base for UpdateBase and SelectBase so it was kind of weird it wasn't there. Fixes: #6661 Fixed issue in CTE constructs mostly relevant to ORM use cases where a recursive CTE against "anonymous" labels such as those seen in ORM ``column_property()`` mappings would render in the ``WITH RECURSIVE xyz(...)`` section as their raw internal label and not a cleanly anonymized name. Fixes: #6663 Change-Id: I26219d4d8e6c0915b641426e9885540f74fae4d2
* don't enable "fast insert executemany" for ON CONFLICT etcMike Bayer2021-06-041-1/+8
| | | | | | | | | | | | | Fixed issue where using the PostgreSQL "INSERT..ON CONFLICT" structure would fail to work with the psycopg2 driver if it were used in an "executemany" context along with bound parameters in the "SET" clause, due to the implicit use of the psycopg2 fast execution helpers which are not appropriate for this style of INSERT statement. Additional checks to exclude this kind of statement from that particular extension have been added. Fixes: #6581 Change-Id: I3d6169e7e188dc087d1d1bfba9a42162db183265
* set bindparam.expanding in coercion againMike Bayer2021-05-101-20/+2
| | | | | | | | | | | | | | | | | Adjusted the logic added as part of :ticket:`6397` in 1.4.12 so that internal mutation of the :class:`.BindParameter` object occurs within the clause construction phase as it did before, rather than in the compilation phase. In the latter case, the mutation still produced side effects against the incoming construct and additionally could potentially interfere with other internal mutation routines. In order to solve the issue of the correct operator being present on the BindParameter.expand_op, we necessarily have to expand the BinaryExpression._negate() routine to flip the operator on the BindParameter also. Fixes: #6460 Change-Id: I1e53a9aeee4de4fc11af51d7593431532731561b
* Add a comment in the compiler on why the NOT IN operatorFederico Caselli2021-05-051-0/+3
| | | | | | is rendered using brackets. Change-Id: I39c2e6a03e8aad7ff27bc6000da5bc9f1de14dc2
* Parenthesize for empty not inMike Bayer2021-05-051-7/+9
| | | | | | | | | | | | | Fixed regression caused by the "empty in" change just made in :ticket:`6397` 1.4.12 where the expression needs to be parenthesized for the "not in" use case, otherwise the condition will interfere with the other filtering criteria. also amends StrSQLCompiler to use the newer "empty IN" style for its compilation process. Fixes: #6428 Change-Id: I182a552fc0d3065a9e38c0f4ece2deb143735c36
* Merge "Use non-subquery form for empty IN"mike bayer2021-04-291-4/+46
|\
| * Use non-subquery form for empty INMike Bayer2021-04-291-4/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revised the "EMPTY IN" expression to no longer rely upon using a subquery, as this was causing some compatibility and performance problems. The new approach for selected databases takes advantage of using a NULL-returning IN expression combined with the usual "1 != 1" or "1 = 1" expression appended by AND or OR. The expression is now the default for all backends other than SQLite, which still had some compatibility issues regarding tuple "IN" for older SQLite versions. Third party dialects can still override how the "empty set" expression renders by implementing a new compiler method ``def visit_empty_set_op_expr(self, type_, expand_op)``, which takes precedence over the existing ``def visit_empty_set_expr(self, element_types)`` which remains in place. Fixes: #6258 Fixes: #6397 Change-Id: I2df09eb00d2ad3b57039ae48128fdf94641b5e59
* | Merge "Propertly ignore ``Identity`` in MySQL and MariaDb."mike bayer2021-04-291-2/+7
|\ \
| * | Propertly ignore ``Identity`` in MySQL and MariaDb.Federico Caselli2021-04-281-2/+7
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that the MySQL and MariaDB dialect ignore the :class:`_sql.Identity` construct while rendering the ``AUTO_INCREMENT`` keyword in a create table. The Oracle and PostgreSQL compiler was updated to not render :class:`_sql.Identity` if the database version does not support it (Oracle < 12 and PostgreSQL < 10). Previously it was rendered regardless of the database version. Fixes: #6338 Change-Id: I2ca0902fdd7b4be4fc1a563cf5585504cbea9360
* | accommodate for mutiple copies of bind in ckbmMike Bayer2021-04-281-4/+4
|/ | | | | | | | | | | | | | | | Fixed critical regression where bound parameter tracking as used in the SQL caching system could fail to track all parameters for the case where the same SQL expression containing a parameter were used in an ORM-related query using a feature such as class inheritance, which was then embedded in an enclosing expression which would make use of that same expression multiple times, such as a UNION. The ORM would individually copy the individual SELECT statements as part of compilation with class inheritance, which then embedded in the enclosing statement would fail to accommodate for all parameters. The logic that tracks this condition has been adjusted to work for multiple copies of a parameter. Fixes: #6391 Change-Id: I6db5dee0d361a3bb58d753a2d27ef2eee2b369c5
* omit text from selected_columns; clear memoizationsMike Bayer2021-04-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Fixed regression where usage of the :func:`_sql.text` construct inside the columns clause of a :class:`_sql.Select` construct, which is better handled by using a :func:`_sql.literal_column` construct, would nonetheless prevent constructs like :func:`_sql.union` from working correctly. Other use cases, such as constructing subuqeries, continue to work the same as in prior versions where the :func:`_sql.text` construct is silently omitted from the collection of exported columns. Also repairs similar use within the ORM. This adds a new internal method _all_selected_columns. The existing "selected_columns" collection can't store a TextClause and this never worked, so they are omitted. The TextClause is also not "exported", i.e. available for SELECT from a subquery, as was already the case in 1.3, so the "exported_columns" and "exported_columns_iterator" accessors are where we now omit TextClause. Fixed regression involving legacy methods such as :meth:`_sql.Select.append_column` where internal assertions would fail. Fixes: #6343 Fixes: #6261 Change-Id: I7c2e5b9ae5d94131c77599a020f4310dcf812bcf
* Propagate compiler kw for visit_values to parametersMike Bayer2021-04-201-2/+2
| | | | | | | | | | | | Fixed issue in SQL compiler where the bound parameters set up for a :class:`.Values` construct wouldn't be positionally tracked correctly if inside of a :class:`_sql.CTE`, affecting database drivers that support VALUES + ctes and use positional parameters such as SQL Server in particular as well as asyncpg. The fix also repairs support for compiler flags such as ``literal_binds``. Fixes: #6327 Change-Id: I2d549228691d0bfc10dadd0955b1549d7584db51
* Merge "Don't stringify unnamed column elements when proxying"mike bayer2021-04-171-1/+1
|\
| * Don't stringify unnamed column elements when proxyingMike Bayer2021-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Repaired and solidified issues regarding custom functions and other arbitrary expression constructs which within SQLAlchemy's column labeling mechanics would seek to use ``str(obj)`` to get a string representation to use as an anonymous column name in the ``.c`` collection of a subquery. This is a very legacy behavior that performs poorly and leads to lots of issues, so has been revised to no longer perform any compilation by establishing specific methods on :class:`.FunctionElement` to handle this case, as SQL functions are the only use case that it came into play. An effect of this behavior is that an unlabeled column expression with no derivable name will be given an arbitrary label starting with the prefix ``"_no_label"`` in the ``.c`` collection of a subquery; these were previously being represented either as the generic stringification of that expression, or as an internal symbol. This change seeks to make the concept of "anon name" more private and renames anon_label and anon_key_label to _anon_name_label and _anon_key_label. There's no end-user utility to these accessors and we need to be able to reorganize these as well. Fixes: #6256 Change-Id: Ie63c86b20ca45873affea78500388da94cf8bf94
* | Merge "pass asfrom correctly in compilers"mike bayer2021-04-171-2/+4
|\ \
| * | pass asfrom correctly in compilersMike Bayer2021-04-171-2/+4
| |/ | | | | | | | | | | | | | | | | | | | | | | Fixed an argument error in the default and PostgreSQL compilers that would interfere with an UPDATE..FROM or DELETE..FROM..USING statement that was then SELECTed from as a CTE. The incorrect pattern was also fixed in the mysql and sybase dialects. MySQL supports CTEs but not "returning". Fixes: #6303 Change-Id: Ic94805611a5ec443749fb6b1fd8a1326b0d83ef7
* | Fit literal compile of empty in on a tupleFederico Caselli2021-04-161-4/+8
|/ | | | | | | | Fixed regression where an empty in statement on a tuple would result in an error when compiled with the option ``literal_binds=True``. Fixes: #6290 Change-Id: Ic0dff8f4a874cccdb201b6d9dcd3c2e7b7884cbb
* Support DEFAULT VALUES and VALUES(DEFAULT) individuallyMike Bayer2021-04-141-0/+1
| | | | | | | | | | | | | Fixed regression where the introduction of the INSERT syntax "INSERT... VALUES (DEFAULT)" was not supported on some backends that do however support "INSERT..DEFAULT VALUES", including SQLite. The two syntaxes are now each individually supported or non-supported for each dialect, for example MySQL supports "VALUES (DEFAULT)" but not "DEFAULT VALUES". Support for Oracle is still not enabled as there are unresolved issues in using RETURNING at the same time. Fixes: #6254 Change-Id: I47959bc826e3d9d2396ccfa290eb084841b02e77
* Return Row for CursorResult.inserted_primary_keyMike Bayer2021-04-111-3/+13
| | | | | | | | | The tuple returned by :attr:`.CursorResult.inserted_primary_key` is now a :class:`_result.Row` object with a named tuple interface on top of the existing tuple interface. Fixes: #3314 Change-Id: I85677ef60d8329648f368bf497f634758f4e087b
* Expand reg for schema translate map for most special charactersMike Bayer2021-04-071-1/+6
| | | | | | | | | | | | 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
* uniquify when popping literal_execute_params from param dictMike Bayer2021-04-051-1/+3
| | | | | | | | | | | 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
* Apply quoting to render_derived() namesMike Bayer2021-04-011-1/+1
| | | | | | | | | | 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
* Deannoate functions before matching .__class__Mike Bayer2021-03-191-1/+1
| | | | | | | | | | 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
* 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 "Fix named CHECK constraint name omitted on repeated creates"mike bayer2021-03-071-5/+2
|\
| * Fix named CHECK constraint name omitted on repeated createsGord Thompson2021-03-061-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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
* Implement support for functions as FROM with columns clause supportMike Bayer2021-02-031-4/+60
| | | | | | | | | | | | | | | | 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
* 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
* 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
* Fix many spell glitches in docstrings and commentsLele Gaifax2021-01-241-2/+2
| | | | | | | | | | 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
* Revert "Implement support for functions as FROM with columns clause support"Mike Bayer2021-01-211-32/+2
| | | | | | | 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-201-2/+32
| | | | | | | WIP Fixes: #3566 Change-Id: I5b093b72533ef695293e737eb75850b9713e5e03
* ``Identity`` implies ``nullable=False``.Federico Caselli2021-01-161-1/+1
| | | | | | | | | | | | | | | 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
* happy new yearMike Bayer2021-01-041-1/+1
| | | | Change-Id: Ic5bb19ca8be3cb47c95a0d3315d84cb484bac47c
* Support TypeDecorator.get_dbapi_type() for setinpusizesMike Bayer2020-12-301-3/+8
| | | | | | | | Adjusted the "setinputsizes" logic relied upon by the cx_Oracle, asyncpg and pg8000 dialects to support a :class:`.TypeDecorator` that includes an override the :meth:`.TypeDecorator.get_dbapi_type()` method. Change-Id: I5aa70abf0d9a9e2ca43309f2dd80b3fcd83881b9
* Improve type detection for Values / TupleMike Bayer2020-12-181-1/+3
| | | | | | | | | | | | | | | | | Fixed issue in new :class:`_sql.Values` construct where passing tuples of objects would fall back to per-value type detection rather than making use of the :class:`_schema.Column` objects passed directly to :class:`_sql.Values` that tells SQLAlchemy what the expected type is. This would lead to issues for objects such as enumerations and numpy strings that are not actually necessary since the expected type is given. note this changes NullType() to raise CompileError for literal_processor; NullType() does not imply the actual value NULL as much as it does "unknown type" so this should make failure modes more clear. Fixes: #5785 Change-Id: Ifbf5e78373102380b301098f30e15011efa98b5e
* Merge "Support IF EXISTS/IF NOT EXISTS for DDL constructs"mike bayer2020-12-141-6/+21
|\
| * Support IF EXISTS/IF NOT EXISTS for DDL constructsRamonWill2020-12-141-6/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Added parameters :paramref:`_ddl.CreateTable.if_not_exists`, :paramref:`_ddl.CreateIndex.if_not_exists`, :paramref:`_ddl.DropTable.if_exists` and :paramref:`_ddl.DropIndex.if_exists` to the :class:`_ddl.CreateTable`, :class:`_ddl.DropTable`, :class:`_ddl.CreateIndex` and :class:`_ddl.DropIndex` constructs which result in "IF NOT EXISTS" / "IF EXISTS" DDL being added to the CREATE/DROP. These phrases are not accepted by all databases and the operation will fail on a database that does not support it as there is no similarly compatible fallback within the scope of a single DDL statement. Pull request courtesy Ramon Williams. Fixes: #2843 Closes: #5663 Pull-request: https://github.com/sqlalchemy/sqlalchemy/pull/5663 Pull-request-sha: 748b8472345d96efb446e2a444fbe020b313669f Change-Id: I6a2b1f697993ed49c31584f0a31887fb0a868ed3
* | Properly render ``cycle=False`` and ``order=False``Federico Caselli2020-12-011-3/+3
|/ | | | | | | | These get rendered as ``NO CYCLE`` and ``NO ORDER`` in :class:`_sql.Sequence` and :class:`_sql.Identity` objects. Fixes: #5738 Change-Id: Ia9ccb5481a104cb32d3b517e99efd5e730c84946
* Merge "Deprecate bind args, execute() methods that were missed"mike bayer2020-10-311-3/+0
|\
| * Deprecate bind args, execute() methods that were missedMike Bayer2020-10-301-3/+0
| | | | | | | | | | | | in particular text(bind), DDL.execute(). Change-Id: Ie85ae9f61219182f5649f68e5f52b4923843199c
View Lorry Controller Status