sqlalchemy.sql.dml.UpdateBase

Undocumented

Set the parameters for the statement. This method raises ``NotImplementedError`` on the base class, and is overridden by :class:`.ValuesBase` to provide the SET/VALUES clause of UPDATE and INSERT.

Make use of a :term:`RETURNING` clause for the purpose of fetching server-side expressions and defaults, for supporting backends only. .. deepalchemy:: The :meth:`.UpdateBase.return_defaults` method is used by the ORM for its internal work in fetching newly generated primary key and server default values, in particular to provide the underyling implementation of the :paramref:`_orm.Mapper.eager_defaults` ORM feature as well as to allow RETURNING support with bulk ORM inserts. Its behavior is fairly idiosyncratic and is not really intended for general use. End users should stick with using :meth:`.UpdateBase.returning` in order to add RETURNING clauses to their INSERT, UPDATE and DELETE statements. Normally, a single row INSERT statement will automatically populate the :attr:`.CursorResult.inserted_primary_key` attribute when executed, which stores the primary key of the row that was just inserted in the form of a :class:`.Row` object with column names as named tuple keys (and the :attr:`.Row._mapping` view fully populated as well). The dialect in use chooses the strategy to use in order to populate this data; if it was generated using server-side defaults and / or SQL expressions, dialect-specific approaches such as ``cursor.lastrowid`` or ``RETURNING`` are typically used to acquire the new primary key value. However, when the statement is modified by calling :meth:`.UpdateBase.return_defaults` before executing the statement, additional behaviors take place **only** for backends that support RETURNING and for :class:`.Table` objects that maintain the :paramref:`.Table.implicit_returning` parameter at its default value of ``True``. In these cases, when the :class:`.CursorResult` is returned from the statement's execution, not only will :attr:`.CursorResult.inserted_primary_key` be populated as always, the :attr:`.CursorResult.returned_defaults` attribute will also be populated with a :class:`.Row` named-tuple representing the full range of server generated values from that single row, including values for any columns that specify :paramref:`_schema.Column.server_default` or which make use of :paramref:`_schema.Column.default` using a SQL expression. When invoking INSERT statements with multiple rows using :ref:`insertmanyvalues <engine_insertmanyvalues>`, the :meth:`.UpdateBase.return_defaults` modifier will have the effect of the :attr:`_engine.CursorResult.inserted_primary_key_rows` and :attr:`_engine.CursorResult.returned_defaults_rows` attributes being fully populated with lists of :class:`.Row` objects representing newly inserted primary key values as well as newly inserted server generated values for each row inserted. The :attr:`.CursorResult.inserted_primary_key` and :attr:`.CursorResult.returned_defaults` attributes will also continue to be populated with the first row of these two collections. If the backend does not support RETURNING or the :class:`.Table` in use has disabled :paramref:`.Table.implicit_returning`, then no RETURNING clause is added and no additional data is fetched, however the INSERT, UPDATE or DELETE statement proceeds normally. E.g.:: stmt = table.insert().values(data='newdata').return_defaults() result = connection.execute(stmt) server_created_at = result.returned_defaults['created_at'] When used against an UPDATE statement :meth:`.UpdateBase.return_defaults` instead looks for columns that include :paramref:`_schema.Column.onupdate` or :paramref:`_schema.Column.server_onupdate` parameters assigned, when constructing the columns that will be included in the RETURNING clause by default if explicit columns were not specified. When used against a DELETE statement, no columns are included in RETURNING by default, they instead must be specified explicitly as there are no columns that normally change values when a DELETE statement proceeds. .. versionadded:: 2.0 :meth:`.UpdateBase.return_defaults` is supported for DELETE statements also and has been moved from :class:`.ValuesBase` to :class:`.UpdateBase`. The :meth:`.UpdateBase.return_defaults` method is mutually exclusive against the :meth:`.UpdateBase.returning` method and errors will be raised during the SQL compilation process if both are used at the same time on one statement. The RETURNING clause of the INSERT, UPDATE or DELETE statement is therefore controlled by only one of these methods at a time. The :meth:`.UpdateBase.return_defaults` method differs from :meth:`.UpdateBase.returning` in these ways: 1. :meth:`.UpdateBase.return_defaults` method causes the :attr:`.CursorResult.returned_defaults` collection to be populated with the first row from the RETURNING result. This attribute is not populated when using :meth:`.UpdateBase.returning`. 2. :meth:`.UpdateBase.return_defaults` is compatible with existing logic used to fetch auto-generated primary key values that are then populated into the :attr:`.CursorResult.inserted_primary_key` attribute. By contrast, using :meth:`.UpdateBase.returning` will have the effect of the :attr:`.CursorResult.inserted_primary_key` attribute being left unpopulated. 3. :meth:`.UpdateBase.return_defaults` can be called against any backend. Backends that don't support RETURNING will skip the usage of the feature, rather than raising an exception. The return value of :attr:`_engine.CursorResult.returned_defaults` will be ``None`` for backends that don't support RETURNING or for which the target :class:`.Table` sets :paramref:`.Table.implicit_returning` to ``False``. 4. An INSERT statement invoked with executemany() is supported if the backend database driver supports the :ref:`insertmanyvalues <engine_insertmanyvalues>` feature which is now supported by most SQLAlchemy-included backends. When executemany is used, the :attr:`_engine.CursorResult.returned_defaults_rows` and :attr:`_engine.CursorResult.inserted_primary_key_rows` accessors will return the inserted defaults and primary keys. .. versionadded:: 1.4 Added :attr:`_engine.CursorResult.returned_defaults_rows` and :attr:`_engine.CursorResult.inserted_primary_key_rows` accessors. In version 2.0, the underlying implementation which fetches and populates the data for these attributes was generalized to be supported by most backends, whereas in 1.4 they were only supported by the ``psycopg2`` driver. :param cols: optional list of column key names or :class:`_schema.Column` that acts as a filter for those columns that will be fetched. :param supplemental_cols: optional list of RETURNING expressions, in the same form as one would pass to the :meth:`.UpdateBase.returning` method. When present, the additional columns will be included in the RETURNING clause, and the :class:`.CursorResult` object will be "rewound" when returned, so that methods like :meth:`.CursorResult.all` will return new rows mostly as though the statement used :meth:`.UpdateBase.returning` directly. However, unlike when using :meth:`.UpdateBase.returning` directly, the **order of the columns is undefined**, so can only be targeted using names or :attr:`.Row._mapping` keys; they cannot reliably be targeted positionally. .. versionadded:: 2.0 .. seealso:: :meth:`.UpdateBase.returning` :attr:`_engine.CursorResult.returned_defaults` :attr:`_engine.CursorResult.returned_defaults_rows` :attr:`_engine.CursorResult.inserted_primary_key` :attr:`_engine.CursorResult.inserted_primary_key_rows`

Add a :term:`RETURNING` or equivalent clause to this statement. e.g.: .. sourcecode:: pycon+sql >>> stmt = ( ... table.update() ... .where(table.c.data == "value") ... .values(status="X") ... .returning(table.c.server_flag, table.c.updated_timestamp) ... ) >>> print(stmt) {printsql}UPDATE some_table SET status=:status WHERE some_table.data = :data_1 RETURNING some_table.server_flag, some_table.updated_timestamp The method may be invoked multiple times to add new entries to the list of expressions to be returned. .. versionadded:: 1.4.0b2 The method may be invoked multiple times to add new entries to the list of expressions to be returned. The given collection of column expressions should be derived from the table that is the target of the INSERT, UPDATE, or DELETE. While :class:`_schema.Column` objects are typical, the elements can also be expressions: .. sourcecode:: pycon+sql >>> stmt = table.insert().returning( ... (table.c.first_name + " " + table.c.last_name).label("fullname") ... ) >>> print(stmt) {printsql}INSERT INTO some_table (first_name, last_name) VALUES (:first_name, :last_name) RETURNING some_table.first_name || :first_name_1 || some_table.last_name AS fullname Upon compilation, a RETURNING clause, or database equivalent, will be rendered within the statement. For INSERT and UPDATE, the values are the newly inserted/updated values. For DELETE, the values are those of the rows which were deleted. Upon execution, the values of the columns to be returned are made available via the result set and can be iterated using :meth:`_engine.CursorResult.fetchone` and similar. For DBAPIs which do not natively support returning values (i.e. cx_oracle), SQLAlchemy will approximate this behavior at the result level so that a reasonable amount of behavioral neutrality is provided. Note that not all databases/DBAPIs support RETURNING. For those backends with no support, an exception is raised upon compilation and/or execution. For those who do support it, the functionality across backends varies greatly, including restrictions on executemany() and other statements which return multiple rows. Please read the documentation notes for the database in use in order to determine the availability of RETURNING. .. seealso:: :meth:`.UpdateBase.return_defaults` - an alternative method tailored towards efficient fetching of server-side defaults and triggers for single-row INSERTs or UPDATEs. :ref:`tutorial_insert_returning` - in the :ref:`unified_tutorial`

Add dialect options to this INSERT/UPDATE/DELETE object. e.g.:: upd = table.update().dialect_options(mysql_limit=10) .. versionadded: 1.4 - this method supersedes the dialect options associated with the constructor.

Add a table hint for a single table to this INSERT/UPDATE/DELETE statement. .. note:: :meth:`.UpdateBase.with_hint` currently applies only to Microsoft SQL Server. For MySQL INSERT/UPDATE/DELETE hints, use :meth:`.UpdateBase.prefix_with`. The text of the hint is rendered in the appropriate location for the database backend in use, relative to the :class:`_schema.Table` that is the subject of this statement, or optionally to that of the given :class:`_schema.Table` passed as the ``selectable`` argument. The ``dialect_name`` option will limit the rendering of a particular hint to a particular backend. Such as, to add a hint that only takes effect for SQL Server:: mytable.insert().with_hint("WITH (PAGLOCK)", dialect_name="mssql") :param text: Text of the hint. :param selectable: optional :class:`_schema.Table` that specifies an element of the FROM clause within an UPDATE or DELETE to be the subject of the hint - applies only to certain backends. :param dialect_name: defaults to ``*``, if specified as the name of a particular dialect, will apply these hints only when that dialect is in use.