| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Change-Id: I0d7f5105f838a0275f3c240441bdcdc9ae7444d0
|
| |
|
|
|
|
| |
includes adjustment to setup.py to recognize __version__ correctly
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactored :class:`.SQLCompiler` to expose a
:meth:`.SQLCompiler.group_by_clause` method similar to the
:meth:`.SQLCompiler.order_by_clause` and :meth:`.SQLCompiler.limit_clause`
methods, which can be overridden by dialects to customize how GROUP BY
renders. Pull request courtesy Samuel Chou.
Change-Id: I0a7238e55032558c27a0c56a72907c7b883456f1
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/474
(cherry picked from commit 33fccc486111fc6b41eab651cc7325c83099ad45)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed issue that is closely related to :ticket:`3639` where an expression
rendered in a boolean context on a non-native boolean backend would
be compared to 1/0 even though it is already an implcitly boolean
expression, when :meth:`.ColumnElement.self_group` were used. While this
does not affect the user-friendly backends (MySQL, SQLite) it was not
handled by Oracle (and possibly SQL Server). Whether or not the
expression is implicitly boolean on any database is now determined
up front as an additional check to not generate the integer comparison
within the compliation of the statement.
Fixes: #4320
Change-Id: Iae0a65e5c01bd576e64733c3651e1e1a1a1b240c
(cherry picked from commit 462ccd9ff18d2e428b20ec3f596391a275472140)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug where the multi-table support for UPDATE and DELETE statements
did not consider the additional FROM elements as targets for correlation,
when a correlated SELECT were also combined with the statement. This
change now includes that a SELECT statement in the WHERE clause for such a
statement will try to auto-correlate back to these additional tables in the
parent UPDATE/DELETE or unconditionally correlate if
:meth:`.Select.correlate` is used. Note that auto-correlation raises an
error if the SELECT statement would have no FROM clauses as a result, which
can now occur if the parent UPDATE/DELETE specifies the same tables in its
additional set of tables ; specify :meth:`.Select.correlate` explicitly to
resolve.
Change-Id: Ie11eaad7e49af3f59df11691b104d6359341bdae
Fixes: #4313
(cherry picked from commit abeea1d82db34232bbef01e98fa4d1de0f583eb6)
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The :class:`.Update` construct now accommodates a :class:`.Join` object
as supported by MySQL for UPDATE..FROM. As the construct already
accepted an alias object for a similar purpose, the feature of UPDATE
against a non-table was already implied so this has been added.
Change-Id: I7b2bca627849384d5377abb0c94626463e4fad04
Fixes: #3645
(cherry picked from commit 58540ae93db30fb12f331587c32bb2d76db79ab3)
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed INSERT FROM SELECT with CTEs for the Oracle and MySQL dialects, where
the CTE was being placed above the entire statement as is typical with
other databases, however Oracle and MariaDB 10.2 wants the CTE underneath
the "INSERT" segment. Note that the Oracle and MySQL dialects don't yet
work when a CTE is applied to a subquery inside of an UPDATE or DELETE
statement, as the CTE is still applied to the top rather than inside the
subquery.
Also adds test suite support CTEs against backends.
Change-Id: I8ac337104d5c546dd4f0cd305632ffb56ac8bf90
Fixes: #4275
Fixes: #4230
(cherry picked from commit 3619edcb8aa3ceef2a44925b85315fc0e90c5982)
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed issue where the compilation of an INSERT statement with the
"literal_binds" option that also uses an explicit sequence and "inline"
generation, as on Postgresql and Oracle, would fail to accommodate the
extra keyword argument within the sequence processing routine.
Change-Id: Ibdab7d340aea7429a210c9535ccf1a3e85f074fb
Fixes: #4231
(cherry picked from commit b4eb29253cb29a069973503f36d1103d4a18311c)
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed a regression that occurred from the previous fix to :ticket:`4204` in
version 1.2.5, where a CTE that refers to itself after the
:meth:`.CTE.alias` method has been called would not refer to iself
correctly.
Change-Id: Iaa63d65ad2b90c8693f9953fbb32dbb10c73a037
Fixes: #4204
(cherry picked from commit ef2859bbc8bb8104bf4e429a52efb50a712d834a)
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug in CTE rendering where a :class:`.CTE` that was also turned into
an :class:`.Alias` would not render its "ctename AS aliasname" clause
appropriately if there were more than one reference to the CTE in a FROM
clause.
Change-Id: If8cff27a2f4faa5eceb59aa86398db6edb3b9e72
Fixes: #4204
(cherry picked from commit 5f60dc649cde2525f5eb1e7008a75304603b751c)
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug where CTE expressions would not have their name or alias name
quoted when the given name is case sensitive or otherwise requires quoting.
Pull request courtesy Eric Atkin.
Fixes: #4197
Change-Id: Ib8573e82b9a1ca94b50c7c5d73ee98b79465d689
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/426
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixed regression in 1.2 where newly repaired quoting
of collation names in :ticket:`3785` breaks SQL Server,
which explicitly does not understand a quoted collation
name. Whether or not mixed-case collation names are
quoted or not is now deferred down to a dialect-level
decision so that each dialect can prepare these identifiers
directly.
Change-Id: Iaf0a8123d9bf4711219e320896bb28c5d2649304
Fixes: #4154
|
|/
|
|
| |
Change-Id: I3ef36bfd0cb0ba62b3123c8cf92370a43156cf8f
|
|
|
|
|
|
|
|
| |
Add codes to commonly raised error messages and classes
that link back to fixed documentation sections
giving background on these messages.
Change-Id: I78d0660add7026bb662e20305a59283b20616954
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented "DELETE..FROM" syntax for Postgresql, MySQL, MS SQL Server
(as well as within the unsupported Sybase dialect) in a manner similar
to how "UPDATE..FROM" works. A DELETE statement that refers to more than
one table will switch into "multi-table" mode and render the appropriate
"USING" or multi-table "FROM" clause as understood by the database.
Pull request courtesy Pieter Mulder.
For SQL syntaxes see:
Postgresql: https://www.postgresql.org/docs/current/static/sql-delete.html
MySQL: https://dev.mysql.com/doc/refman/5.7/en/delete.html#multiple-table_syntax
MSSQL: https://docs.microsoft.com/en-us/sql/t-sql/statements/delete-transact-sql
Sybase: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc00801.1510/html/iqrefso/X315721.htm
Co-authored by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I6dfd57b49e44a095d076dc493cd2360bb5d920d3
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/392
Fixes: #959
|
|
|
|
|
|
|
|
| |
Fixes: #3429
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I870ee7dc801d553c5309c291402ec468b671e9a9
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/383
|
|
|
|
|
|
|
|
|
|
|
| |
Altered the range specification for window functions to allow
for two of the same PRECEDING or FOLLOWING keywords in a range
by allowing for the left side of the range to be positive
and for the right to be negative, e.g. (1, 3) is
"1 FOLLOWING AND 3 FOLLOWING".
Change-Id: I7d3a6c641151bb49219104968d18dac2266f3db8
Fixes: #4053
|
|
|
|
|
|
|
|
|
|
|
| |
Added new keywords :paramref:`.Sequence.cache` and
:paramref:`.Sequence.order` to :class:`.Sequence`, to allow rendering
of the CACHE parameter understood by Oracle and PostgreSQL, and the
ORDER parameter understood by Oracle. Pull request
courtesy David Moore.
Change-Id: I082c3f8ef56ef89dbaad5da9d5695be5313b0614
Pull-request: https://bitbucket.org/zzzeek/sqlalchemy/pull-requests/96
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new kind of :func:`.bindparam` called "expanding". This is
for use in ``IN`` expressions where the list of elements is rendered
into individual bound parameters at statement execution time, rather
than at statement compilation time. This allows both a single bound
parameter name to be linked to an IN expression of multiple elements,
as well as allows query caching to be used with IN expressions. The
new feature allows the related features of "select in" loading and
"polymorphic in" loading to make use of the baked query extension
to reduce call overhead. This feature should be considered to be
**experimental** for 1.2.
Fixes: #3953
Change-Id: Ie708414a3ab9c0af29998a2c7f239ff7633b1f6e
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch moves the "doubling" of percent signs into
the base compiler and makes it completely a product
of whether or not the paramstyle is format/pyformat or
not. Without this paramstyle, percent signs
are not doubled across text(), literal_column(), and
column().
Change-Id: Ie2f278ab1dbb94b5078f85c0096d74dbfa049197
Fixes: #3740
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug where a column-level :class:`.CheckConstraint` would fail
to compile the SQL expression using the underlying dialect compiler
as well as apply proper flags to generate literal values as
inline, in the case that the sqltext is a Core expression and
not just a plain string. This was long-ago fixed for table-level
check constraints in 0.9 as part of :ticket:`2742`, which more commonly
feature Core SQL expressions as opposed to plain string expressions.
Change-Id: I1301ba4b40063e91bc47726aecc5f4990ffcaeda
Fixes: #3957
|
|
|
|
|
|
|
| |
After bump minimum supported version to 2.7 (1da9d3752160430c91534a8868ceb8c5ad1451d4), we can use new syntax.
Change-Id: Ib064c75a00562e641d132f9c57e5e69744200e05
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/347
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added support for SQL comments on :class:`.Table` and :class:`.Column`
objects, via the new :paramref:`.Table.comment` and
:paramref:`.Column.comment` arguments. The comments are included
as part of DDL on table creation, either inline or via an appropriate
ALTER statement, and are also reflected back within table reflection,
as well as via the :class:`.Inspector`. Supported backends currently
include MySQL, Postgresql, and Oracle.
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Fixes: #1546
Change-Id: Ib90683850805a2b4ee198e420dc294f32f15d35d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The longstanding behavior of the :meth:`.Operators.in_` and
:meth:`.Operators.not_in_` operators emitting a warning when
the right-hand condition is an empty sequence has been revised;
a new flag :paramref:`.create_engine.empty_in_strategy` allows an
empty "IN" expression to generate a simple boolean expression, or
to invoke the previous behavior of dis-equating the expression to
itself, with or without a warning. The default behavior is now
to emit the simple boolean expression, allowing an empty IN to
be evaulated without any performance penalty.
Change-Id: I65cc37f2d7cf65a59bf217136c42fee446929352
Fixes: #3907
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug in compiler where the string identifier of a savepoint would
be cached in the identifier quoting dictionary; as these identifiers
are arbitrary, a small memory leak could occur if a single
:class:`.Connection` had an unbounded number of savepoints used,
as well as if the savepoint clause constructs were used directly
with an unbounded umber of savepoint names. The memory leak does
**not** impact the vast majority of cases as normally the
:class:`.Connection`, which renders savepoint names with a simple
counter starting at "1", is used on a per-transaction or
per-fixed-number-of-transactions basis before being discarded.
The savepoint name in virtually all cases does not require quoting
at all, however to support potential third party use cases
the "check for quotes needed" logic is retained, at a small
performance cost. Uncondtionally quoting the name is another
option, but this would turn the name into a case sensitive name
which runs the risk of poor interactions with existing deployments
that may be looking at these names in other contexts.
Change-Id: I6b53c96abf7fdf1840592bbca5da81347911844c
Fixes: #3931
|
|
|
|
|
|
|
|
|
|
|
| |
Corrects some warnings and adds tox config. Adds DeprecationWarning
to the error category. Large sweep for string literals w/ backslashes
as this is common in docstrings
Co-authored-by: Andrii Soldatenko
Fixes: #3886
Change-Id: Ia7c838dfbbe70b262622ed0803d581edc736e085
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/337
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Fixed bug originally introduced in 0.9 via :ticket:`1068` where
order_by(<some Label()>) would order by the label name based on name
alone, that is, even if the labeled expression were not at all the same
expression otherwise present, implicitly or explicitly, in the
selectable. The logic that orders by label now ensures that the
labeled expression is related to the one that resolves to that name
before ordering by the label name; additionally, the name has to
resolve to an actual label explicit in the expression elsewhere, not
just a column name. This logic is carefully kept separate from the
order by(textual name) feature that has a slightly different purpose.
Change-Id: I44fc36dab34380cc238c1e79ecbe23f1628d588a
Fixes: #3882
|
|/
|
|
| |
Change-Id: I4e8c2aa8fe817bb2af8707410fa0201f938781de
|
|
|
|
|
|
|
|
| |
Compiler can now set up execution options and additionally
will propagate autocommit from embedded CTEs.
Change-Id: I19db7b8fe4d84549ea95342e8d2040189fed1bbe
Fixes: #3805
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added compiler-level flags used by Postgresql to place additional
parenthesis than would normally be generated by precedence rules
around operations involving JSON, HSTORE indexing operators as well as
within their operands since it has been observed that Postgresql's
precedence rules for at least the HSTORE indexing operator is not
consistent between 9.4 and 9.5.
Fixes: #3806
Change-Id: I5899677b330595264543b055abd54f3c76bfabf2
|
|
|
|
|
|
|
|
|
|
|
| |
A string sent as a column default via the
:paramref:`.Column.server_default` parameter is now escaped for quotes.
This change is backwards compatible with code that may have been
working around this previously.
Change-Id: I341298a76cc67bc0a53df4ab51ab9379f2294cdd
Fixes: #3809
|
|
|
|
|
|
|
|
|
|
| |
Stringify of expression with unnamed :class:`.Column` objects, as
occurs in lots of situations including ORM error reporting,
will now render the name in string context as "<name unknown>"
rather than raising a compile error.
Change-Id: I76f637c5eb4cfdb1b526964cb001565b97e296da
Fixes: #3789
|
|
|
|
|
|
|
|
|
|
| |
Raise a more descriptive exception / message when ClauseElement
or non-SQLAlchemy objects that are not "executable" are erroneously
passed to ``.execute()``; a new exception ObjectNotExecutableError
is raised consistently in all cases.
Change-Id: I2dd393121e2c7e5b6b9e40286a2f25670876e8e4
Fixes: #3786
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug in new CTE feature for update/insert/delete stated
as a CTE inside of an enclosing statement (typically SELECT) whereby
oninsert and onupdate values weren't called upon for the embedded
statement.
This is accomplished by consulting prefetch
for all statements. The collection is also broken into
separate insert/update collections so that we don't need to
consult toplevel self.isinsert to determine if the prefetch
is for an insert or an update. What we don't yet test for
are CTE combinations that have both insert/update in one
statement, though these should now work in theory provided
the underlying database supports such a statement.
Change-Id: I3b6a860e22c86743c91c56a7ec751ff706f66f64
Fixes: #3745
|
|
|
|
|
|
|
|
|
|
|
| |
Dialed back the "order the primary key columns per auto-increment"
described in :ref:`change_mysql_3216` a bit, so that if the
:class:`.PrimaryKeyConstraint` is explicitly defined, the order
of columns is maintained exactly, allowing control of this behavior
when necessary.
Change-Id: I9e7902c57a96c15968a6abf53e319acf15680da0
Fixes: #3726
|
|
|
|
|
|
|
| |
Allows custom dialects to add keywords after the
CREATE TABLE section.
Change-Id: I6fa66dfcf00ef95122f491a9115410df2746cf88
|
|
|
|
|
|
|
|
|
|
| |
The TABLESAMPLE clause allows randomly selecting an approximate percentage
of rows from a table. At least DB2, Microsoft SQL Server and recent
Postgresql support this standard clause.
Fixes: #3718
Change-Id: I3fb8b9223e12a57100df30876b461884c58d72fa
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/277
|
|
|
|
|
|
|
| |
Fixes: #3529
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: Ie3bf6ad70d9be9f0e44938830e922db03573991a
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/258
|
|
|
|
|
|
|
| |
Fixes: #3049
Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: Ie572095c3e25f70a1e72e1af6858e5edd89fd25e
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/264
|
|
|
|
|
|
|
|
|
|
|
| |
None / True / False render as literals.
For SQLite, "IS" is used as SQLite lacks
"IS DISTINCT FROM" but its "IS" operator acts
this way for NULL.
Doctext-author: Mike Bayer <mike_mp@zzzcomputing.com>
Change-Id: I9227b81f7207b42627a0349d14d40b46aa756cce
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/248
|
|
|
|
|
| |
for the SQL standard LATERAL keyword, currently only supported
by Postgresql. fixes #2857
|
|
|
|
| |
Pull request courtesy Stefan Urbanek. fixes #1957
|
|
|
|
|
|
|
| |
be properly typed as boolean in the result, and also would fail to be
anonymously aliased in a SELECT list as is the case with a
non-negated EXISTS construct.
fixes #3682
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
8ad968f33100baeb3b13c7e0b724b6b79ab4277f
for ref #3657. The Oracle dialect makes more use of the "select_wraps_for"
feature than SQL server because Oracle doesn't have "TOP" for a limit-only
select, so tests are showing more happening here. In the case where
the select() has some dupe columns, these are deduped from the .c collection
so a positional match between the wrapper and original can't use .inner_columns,
because these collections wont match. Using _columns_plus_names
instead which is the deduped collection that determines the SELECT display,
which definitely have to match up.
(cherry picked from commit aa9ce3f521f254da9879ede011e520ec35b8270e)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
handled within visit_select(); this attribute was added in the
1.0 series to accommodate the subquery wrapping behavior of
SQL Server and Oracle while also working with positional
column targeting and no longer relying upon "key fallback"
in order to target columns in such a statement. The IBM DB2
third-party dialect also has this use case, but its implementation
is using regular expressions to rewrite the textual SELECT only
and does not make use of a "wrapped" select at this time.
The logic no longer attempts to reconcile proxy set collections as
this was not deterministic, and instead assumes that the select()
and the wrapper select() match their columns postionally,
at least for the column positions they have in common,
so it is now very simple and safe. fixes #3657.
- as a side effect of #3657 it was also revealed that the
strategy of calling upon a ResultProxy._getter was not
correctly calling into NoSuchColumnError when an expected
column was not present, and instead returned None up to
loading.instances() to produce NoneType failures; added
a raiseerr argument to _getter() which is called when we
aren't expecting None, fixes #3658.
|
|
|
|
|
|
|
| |
INSERT, UPDATE, and DELETE statements to both specify their own
WITH clause, as well as for these statements themselves to be
CTE expressions when they include a RETURNING clause.
fixes #2551
|