| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A SQL expression can now be assigned to a primary key attribute for an ORM
flush in the same manner as ordinary attributes as described in
:ref:`flush_embedded_sql_expressions` where the expression will be evaulated
and then returned to the ORM using RETURNING, or in the case of pysqlite,
works using the cursor.lastrowid attribute.Requires either a database that
supports RETURNING (e.g. Postgresql, Oracle, SQL Server) or pysqlite.
Fixes: #3133
Fixes: #4494
Change-Id: I83da8357354de002cb04fa4a553f2a2f90c5157d
|
|
|
|
| |
Change-Id: I6a71f4924d046cf306961c58dffccf21e9c03911
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Applied on top of a pure run of black -l 79 in
I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9, this set of changes
resolves all remaining flake8 conditions for those codes
we have enabled in setup.cfg.
Included are resolutions for all remaining flake8 issues
including shadowed builtins, long lines, import order, unused
imports, duplicate imports, and docstring issues.
Change-Id: I4f72d3ba1380dd601610ff80b8fb06a2aff8b0fe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a straight reformat run using black as is, with no edits
applied at all.
The black run will format code consistently, however in
some cases that are prevalent in SQLAlchemy code it produces
too-long lines. The too-long lines will be resolved in the
following commit that will resolve all remaining flake8 issues
including shadowed builtins, long lines, import order, unused
imports, duplicate imports, and docstring issues.
Change-Id: I7eda77fed3d8e73df84b3651fd6cfcfe858d4dc9
|
|
|
|
| |
Change-Id: I3ef36bfd0cb0ba62b3123c8cf92370a43156cf8f
|
|
|
|
|
|
|
|
|
|
| |
Fixed bug in :meth:`.Insert.values` where using the "multi-values"
format in combination with :class:`.Column` objects as keys rather
than strings would fail. Pull request courtesy Aubrey Stark-Toller.
Change-Id: I9d3b40b5950df8f5bfdc8b1d22f9c3afb277f17f
Pull-request: https://github.com/zzzeek/sqlalchemy/pull/412
Fixes: #4162
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new method :class:`.DefaultExecutionContext.current_parameters`
which is used within a function-based default value generator in
order to retrieve the current parameters being passed to the statement.
The new function differs from the ``.current_parameters`` attribute in
that it also provides for optional grouping of parameters that
correspond to a multi-valued "insert" construct. Previously it was not
possible to identify the subset of parameters that were relevant to
the function call.
Change-Id: I6894c7b4a2bce3e83c3ade8af0e5b2f8df37b785
Fixes: #4075
|
|
|
|
|
|
|
|
|
| |
Fixed bug where literal_binds compiler flag was not honored by the
:class:`.Insert` construct for the "multiple values" feature; the
subsequent values are now rendered as literals.
Change-Id: I81ac358fd59995885d482e7571620090210865d2
Fixes: #3880
|
|
|
|
| |
Change-Id: I4e8c2aa8fe817bb2af8707410fa0201f938781de
|
|
|
|
|
|
|
|
| |
Fixed bug where an INSERT from SELECT where the source table contains
an autoincrementing Sequence would fail to compile correctly.
Change-Id: I41eb9f65789a4007712ae61ed5fa23a9839a5128
Fixes: #3877
|
|
|
|
|
|
|
|
|
|
| |
PrimaryKeyConstraint is present on Table however
on table() and others it's a ColumnSet. The warning
here only needs len() and PrimaryKeyConstraint supports that
directly in the same way as ColumnSet.
Change-Id: I19c11a39110bfef48cdea49a471e7ab80b537538
Fixes: #3842
|
|
|
|
|
|
|
|
|
|
| |
Changed the naming convention used when generating bound parameters
for a multi-VALUES insert statement, so that the numbered parameter
names don't conflict with the anonymized parameters of a WHERE clause,
as is now common in a PostgreSQL ON CONFLICT construct.
Change-Id: I3188d100fe4d322a47d344d6a63d3e40b915f228
Fixes: #3828
|
|
|
|
|
|
|
|
| |
Users are complaining that IntegrityError is no longer
raised.
Change-Id: I0855d5b7a98d4338f0910501b6e6d404ba33634d
Fixes: #3216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
#3666.
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
insert-default holding columns not otherwise included in the SET
clause (such as primary key cols) to get rendered into the RETURNING
even though this is an UPDATE.
- Major fixes to the :paramref:`.Mapper.eager_defaults` flag, this
flag would not be honored correctly in the case that multiple
UPDATE statements were to be emitted, either as part of a flush
or a bulk update operation. Additionally, RETURNING
would be emitted unnecessarily within update statements.
fixes #3609
|
|
|
|
|
|
|
|
|
|
|
| |
the :class:`.Select` construct would have its ``._raw_columns``
collection mutated in-place when compiling the :class:`.Insert`
construct, when the target :class:`.Table` has Python-side defaults.
The :class:`.Select` construct would compile standalone with the
erroneous column present subsequent to compilation of the
:class:`.Insert`, and the the :class:`.Insert` statement itself would
fail on a second compile attempt due to duplicate bound parameters.
fixes #3603
|
|
|
|
|
|
|
|
|
|
| |
statement. This feature is available by passing the
:paramref:`~.sqlalchemy.sql.expression.update.preserve_parameter_order`
flag either to the core :class:`.Update` construct or alternatively
adding it to the :paramref:`.Query.update.update_args` dictionary at
the ORM-level, also passing the parameters themselves as a list of 2-tuples.
Thanks to Gorka Eguileor for implementation and tests.
adapted from pullreq github:200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"auto increment" column has been changed, such that autoincrement
is no longer implicitly enabled for a :class:`.Table` that has a
composite primary key. In order to accommodate being able to enable
autoincrement for a composite PK member column while at the same time
maintaining SQLAlchemy's long standing behavior of enabling
implicit autoincrement for a single integer primary key, a third
state has been added to the :paramref:`.Column.autoincrement` parameter
``"auto"``, which is now the default. fixes #3216
- The MySQL dialect no longer generates an extra "KEY" directive when
generating CREATE TABLE DDL for a table using InnoDB with a
composite primary key with AUTO_INCREMENT on a column that isn't the
first column; to overcome InnoDB's limitation here, the PRIMARY KEY
constraint is now generated with the AUTO_INCREMENT column placed
first in the list of columns.
|
|
|
|
|
|
|
|
| |
insert statement, :ticket:`3288`, where the column type for the
default-holding column would not be propagated to the compiled
statement in the case where the default was being used,
leading to bind-level type handlers not being invoked.
fixes #3520
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
repaired to work more usefully with tables that have Python-
side default values and/or functions, as well as server-side
defaults. The feature will now work with a dialect that uses
"positional" parameters; a Python callable will also be
invoked individually for each row just as is the case with an
"executemany" style invocation; a server- side default column
will no longer implicitly receive the value explicitly
specified for the first row, instead refusing to invoke
without an explicit value. fixes #3288
|
|
|
|
|
|
|
| |
defaults if otherwise unspecified; the limitation where non-
server column defaults aren't included in an INSERT FROM
SELECT is now lifted and these expressions are rendered as
constants into the SELECT statement.
|
|
CC goes from F to D
|