summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql/dml.py
Commit message (Collapse)AuthorAgeFilesLines
* New features from python 2.7Катаев Денис2017-03-171-2/+2
| | | | | | | 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
* Support python3.6Mike Bayer2017-01-131-13/+13
| | | | | | | | | | | 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
* update for 2017 copyrightMike Bayer2017-01-041-1/+1
| | | | Change-Id: I4e8c2aa8fe817bb2af8707410fa0201f938781de
* spelling: Postgresql -> PostgreSQLVille Skyttä2016-10-081-1/+1
|
* Spelling fixesVille Skyttä2016-10-081-1/+1
|
* Ensure DML provides named_with_column for CTE(Alias)Mike Bayer2016-07-131-0/+1
| | | | | | | | | | | | Fixed bug in new CTE feature for update/insert/delete whereby an anoymous (e.g. no name passed) :class:`.CTE` construct around the statement would fail. The Alias base class of CTE checks for the "named_with_column" attribute in order to detect if the underlying selectable has a name; UpdateBase now provides this as False. Change-Id: I4b0309db21379a4c0cb93085298c86da3cf840e4 Fixes: #3744
* Add ON CONFLICT support for PostgresqlRobin Thomas2016-06-141-0/+1
| | | | | | | Fixes: #3529 Co-authored-by: Mike Bayer <mike_mp@zzzcomputing.com> Change-Id: Ie3bf6ad70d9be9f0e44938830e922db03573991a Pull-request: https://github.com/zzzeek/sqlalchemy/pull/258
* - CTE functionality has been expanded to support all DML, allowingMike Bayer2016-02-111-3/+6
| | | | | | | 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
* - happy new yearMike Bayer2016-01-291-1/+1
|
* some spelling fixesjonathan vanasco2015-12-161-3/+3
|
* - Added support for parameter-ordered SET clauses in an UPDATEMike Bayer2015-11-281-60/+102
| | | | | | | | | | 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
* - try to note under insert.values(), if you needMike Bayer2015-07-081-3/+7
| | | | | | "multiple parameter sets" there is a much more common case which works equally well for INSERT/UPDATE/DELETE e.g. executemany(). reference #3476
* - ensure that the keys we put into the parameters dictionaryMike Bayer2015-04-081-2/+4
| | | | | | | for an insert from select are the string names, and not the Column objects. The MSSQL dialect in particular relies upon checking for these keys in params to know if identity insert should be on. references #3360
* - copyright 2015Mike Bayer2015-03-101-1/+1
|
* - The multi-values version of :meth:`.Insert.values` has beenMike Bayer2015-01-131-0/+6
| | | | | | | | | | | | 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
* Maul the evaulate & friends typoPriit Laes2014-12-191-1/+1
|
* - :meth:`.Insert.from_select` now includes Python and SQL-expressionMike Bayer2014-10-101-8/+18
| | | | | | | 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.
* Fix copy-paste error in Delete docGunnlaugur Þór Briem2014-08-211-2/+2
|
* - fix linkMike Bayer2014-08-211-1/+1
|
* - The INSERT...FROM SELECT construct now implies ``inline=True``Mike Bayer2014-08-201-13/+21
| | | | | | | | | | | | | | | | | | | | | | | on :class:`.Insert`. This helps to fix a bug where an INSERT...FROM SELECT construct would inadvertently be compiled as "implicit returning" on supporting backends, which would cause breakage in the case of an INSERT that inserts zero rows (as implicit returning expects a row), as well as arbitrary return data in the case of an INSERT that inserts multiple rows (e.g. only the first row of many). A similar change is also applied to an INSERT..VALUES with multiple parameter sets; implicit RETURNING will no longer emit for this statement either. As both of these constructs deal with varible numbers of rows, the :attr:`.ResultProxy.inserted_primary_key` accessor does not apply. Previously, there was a documentation note that one may prefer ``inline=True`` with INSERT..FROM SELECT as some databases don't support returning and therefore can't do "implicit" returning, but there's no reason an INSERT...FROM SELECT needs implicit returning in any case. Regular explicit :meth:`.Insert.returning` should be used to return variable numbers of result rows if inserted data is needed. fixes #3169
* - apply pep8 formatting to sqlalchemy/sql, sqlalchemy/util, sqlalchemy/dialects,Brian Jarrett2014-07-201-90/+93
| | | | sqlalchemy/orm, sqlalchemy/event, sqlalchemy/testing
* - break up the <authors> copyright comment as part of a passMike Bayer2014-07-091-1/+2
| | | | to get all flake8 passing
* - Fixed bug where calling :meth:`.Insert.values` with an empty listMike Bayer2014-02-191-0/+1
| | | | | or tuple would raise an IndexError. It now produces an empty insert construct as would be the case with an empty dictionary.
* - implement kwarg validation and type system for dialect-specificMike Bayer2014-01-181-9/+8
| | | | | arguments; [ticket:2866] - add dialect specific kwarg functionality to ForeignKeyConstraint, ForeignKey
* - happy new yearMike Bayer2014-01-051-1/+1
|
* - improve documentation for return_defaults() and returned_defaults. ↵Mike Bayer2013-12-201-26/+59
| | | | [ticket:2852]
* - Fixed bug with :meth:`.Insert.from_select` method where the orderMike Bayer2013-12-191-1/+9
| | | | | | | | of the given names would not be taken into account when generating the INSERT statement, thus producing a mismatch versus the column names in the given SELECT statement. Also noted that :meth:`.Insert.from_select` implies that Python-side insert defaults cannot be used, since the statement has no VALUES clause. [ticket:2895]
* - restore constructor docs blown away in the mergeMike Bayer2013-08-251-0/+141
|
* - The ``version_id_generator`` parameter of ``Mapper`` can now be specifiedMike Bayer2013-08-251-141/+61
| | | | | | | | | | | | | | | | | | | | | to rely upon server generated version identifiers, using triggers or other database-provided versioning features, by passing the value ``False``. The ORM will use RETURNING when available to immediately load the new version identifier, else it will emit a second SELECT. [ticket:2793] - The ``eager_defaults`` flag of :class:`.Mapper` will now allow the newly generated default values to be fetched using an inline RETURNING clause, rather than a second SELECT statement, for backends that support RETURNING. - Added a new variant to :meth:`.ValuesBase.returning` called :meth:`.ValuesBase.return_defaults`; this allows arbitrary columns to be added to the RETURNING clause of the statement without interfering with the compilers usual "implicit returning" feature, which is used to efficiently fetch newly generated primary key values. For supporting backends, a dictionary of all fetched values is present at :attr:`.ResultProxy.returned_defaults`. - add a glossary entry for RETURNING - add documentation for version id generation, [ticket:867]
* - header commentsMike Bayer2013-08-121-1/+1
|
* - A large refactoring of the ``sqlalchemy.sql`` package has reorganizedMike Bayer2013-08-121-0/+668
the import structure of many core modules. ``sqlalchemy.schema`` and ``sqlalchemy.types`` remain in the top-level package, but are now just lists of names that pull from within ``sqlalchemy.sql``. Their implementations are now broken out among ``sqlalchemy.sql.type_api``, ``sqlalchemy.sql.sqltypes``, ``sqlalchemy.sql.schema`` and ``sqlalchemy.sql.ddl``, the last of which was moved from ``sqlalchemy.engine``. ``sqlalchemy.sql.expression`` is also a namespace now which pulls implementations mostly from ``sqlalchemy.sql.elements``, ``sqlalchemy.sql.selectable``, and ``sqlalchemy.sql.dml``. Most of the "factory" functions used to create SQL expression objects have been moved to classmethods or constructors, which are exposed in ``sqlalchemy.sql.expression`` using a programmatic system. Care has been taken such that all the original import namespaces remain intact and there should be no impact on any existing applications. The rationale here was to break out these very large modules into smaller ones, provide more manageable lists of function names, to greatly reduce "import cycles" and clarify the up-front importing of names, and to remove the need for redundant functions and documentation throughout the expression package.
View Lorry Controller Status