summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/sql/dml.py
Commit message (Collapse)AuthorAgeFilesLines
* - 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