SQLAlchemy¶
This document only include partial usages of SQLAlchemy library for this project.
Please refer to the SQLAlchemy official documentation for detail information.
sqlalchemy.pool.base¶
Base constructs for connection pools.
-
class
Pool
(creator, recycle=- 1, echo=None, use_threadlocal=False, logging_name=None, reset_on_return=True, listeners=None, events=None, dialect=None, pre_ping=False, _dispatch=None)¶ Abstract base class for connection pools.
-
add_listener
(listener)¶ Add a
PoolListener
-like object to this pool.Deprecated since version 0.7: The
_pool.Pool.add_listener()
method is deprecated and will be removed in a future release. Please use the_events.PoolEvents
listener interface.listener
may be an object that implements some or all of PoolListener, or a dictionary of callables containing implementations of some or all of the named methods in PoolListener.
-
connect
()¶ Return a DBAPI connection from the pool.
The connection is instrumented such that when its
close()
method is called, the connection will be returned to the pool.
-
dispose
()¶ Dispose of this pool.
This method leaves the possibility of checked-out connections remaining open, as it only affects connections that are idle in the pool.
See also
-
recreate
()¶ Return a new
_pool.Pool
, of the same class as this one and configured with identical creation arguments.This method is used in conjunction with
dispose()
to close out an entire_pool.Pool
and create a new one in its place.
-
unique_connection
()¶ Produce a DBAPI connection that is not referenced by any thread-local context.
This method is equivalent to
_pool.Pool.connect()
when the :paramref:`_pool.Pool.use_threadlocal` flag is not set to True. When :paramref:`_pool.Pool.use_threadlocal` is True, the_pool.Pool.unique_connection()
method provides a means of bypassing the threadlocal context.
-
sqlalchemy.engine.base¶
-
class
Engine
(pool, dialect, url, logging_name=None, echo=None, proxy=None, execution_options=None, hide_parameters=False)¶ Connects a
Pool
andDialect
together to provide a source of database connectivity and behavior.An
_engine.Engine
object is instantiated publicly using thecreate_engine()
function.See also
/core/engines
connections_toplevel
-
begin
(close_with_result=False)¶ Return a context manager delivering a
_engine.Connection
with aTransaction
established.E.g.:
with engine.begin() as conn: conn.execute("insert into table (x, y, z) values (1, 2, 3)") conn.execute("my_special_procedure(5)")
Upon successful operation, the
Transaction
is committed. If an error is raised, theTransaction
is rolled back.The
close_with_result
flag is normallyFalse
, and indicates that the_engine.Connection
will be closed when the operation is complete. When set toTrue
, it indicates the_engine.Connection
is in “single use” mode, where the_engine.ResultProxy
returned by the first call to_engine.Connection.execute()
will close the_engine.Connection
when that_engine.ResultProxy
has exhausted all result rows.See also
_engine.Engine.connect()
- procure a_engine.Connection
from an_engine.Engine
._engine.Connection.begin()
- start aTransaction
for a particular_engine.Connection
.
-
connect
(**kwargs)¶ Return a new
_engine.Connection
object.The
_engine.Connection
object is a facade that uses a DBAPI connection internally in order to communicate with the database. This connection is procured from the connection-holding_pool.Pool
referenced by this_engine.Engine
. When the_engine.Connection.close()
method of the_engine.Connection
object is called, the underlying DBAPI connection is then returned to the connection pool, where it may be used again in a subsequent call to_engine.Engine.connect()
.
-
contextual_connect
(close_with_result=False, **kwargs)¶ Return a
_engine.Connection
object which may be part of some ongoing context.Deprecated since version 1.3: The
_engine.Engine.contextual_connect()
method is deprecated. This method is an artifact of the threadlocal engine strategy which is also to be deprecated. For explicit connections from an_engine.Engine
, use the_engine.Engine.connect()
method.By default, this method does the same thing as
_engine.Engine.connect()
. Subclasses of_engine.Engine
may override this method to provide contextual behavior.- Parameters
close_with_result – When True, the first
_engine.ResultProxy
created by the_engine.Connection
will call the_engine.Connection.close()
method of that connection as soon as any pending result rows are exhausted. This is used to supply the “connectionless execution” behavior provided by the_engine.Engine.execute()
method.
-
dispose
()¶ Dispose of the connection pool used by this
_engine.Engine
.This has the effect of fully closing all currently checked in database connections. Connections that are still checked out will not be closed, however they will no longer be associated with this
_engine.Engine
, so when they are closed individually, eventually the_pool.Pool
which they are associated with will be garbage collected and they will be closed out fully, if not already closed on checkin.A new connection pool is created immediately after the old one has been disposed. This new pool, like all SQLAlchemy connection pools, does not make any actual connections to the database until one is first requested, so as long as the
_engine.Engine
isn’t used again, no new connections will be made.See also
engine_disposal
-
execute
(statement, *multiparams, **params)¶ Executes the given construct and returns a
_engine.ResultProxy
.The arguments are the same as those used by
_engine.Connection.execute()
.Here, a
_engine.Connection
is acquired using the_engine.Engine.contextual_connect()
method, and the statement executed with that connection. The returned_engine.ResultProxy
is flagged such that when the_engine.ResultProxy
is exhausted and its underlying cursor is closed, the_engine.Connection
created here will also be closed, which allows its associated DBAPI connection resource to be returned to the connection pool.
-
execution_options
(**opt)¶ Return a new
_engine.Engine
that will provide_engine.Connection
objects with the given execution options.The returned
_engine.Engine
remains related to the original_engine.Engine
in that it shares the same connection pool and other state:The
_pool.Pool
used by the new_engine.Engine
is the same instance. The_engine.Engine.dispose()
method will replace the connection pool instance for the parent engine as well as this one.Event listeners are “cascaded” - meaning, the new
_engine.Engine
inherits the events of the parent, and new events can be associated with the new_engine.Engine
individually.The logging configuration and logging_name is copied from the parent
_engine.Engine
.
The intent of the
_engine.Engine.execution_options()
method is to implement “sharding” schemes where multiple_engine.Engine
objects refer to the same connection pool, but are differentiated by options that would be consumed by a custom event:primary_engine = create_engine("mysql://") shard1 = primary_engine.execution_options(shard_id="shard1") shard2 = primary_engine.execution_options(shard_id="shard2")
Above, the
shard1
engine serves as a factory for_engine.Connection
objects that will contain the execution optionshard_id=shard1
, andshard2
will produce_engine.Connection
objects that contain the execution optionshard_id=shard2
.An event handler can consume the above execution option to perform a schema switch or other operation, given a connection. Below we emit a MySQL
use
statement to switch databases, at the same time keeping track of which database we’ve established using the_engine.Connection.info
dictionary, which gives us a persistent storage space that follows the DBAPI connection:from sqlalchemy import event from sqlalchemy.engine import Engine shards = {"default": "base", shard_1: "db1", "shard_2": "db2"} @event.listens_for(Engine, "before_cursor_execute") def _switch_shard(conn, cursor, stmt, params, context, executemany): shard_id = conn._execution_options.get('shard_id', "default") current_shard = conn.info.get("current_shard", None) if current_shard != shard_id: cursor.execute("use %s" % shards[shard_id]) conn.info["current_shard"] = shard_id
See also
_engine.Connection.execution_options()
- update execution options on a_engine.Connection
object._engine.Engine.update_execution_options()
- update the execution options for a given_engine.Engine
in place._engine.Engine.get_execution_options()
-
get_execution_options
()¶ Get the non-SQL options which will take effect during execution.
See also
_engine.Engine.execution_options()
-
has_table
(table_name, schema=None)¶ Return True if the given backend has a table of the given name.
See also
metadata_reflection_inspector - detailed schema inspection using the
_reflection.Inspector
interface.quoted_name
- used to pass quoting information along with a schema identifier.
-
raw_connection
(_connection=None)¶ Return a “raw” DBAPI connection from the connection pool.
The returned object is a proxied version of the DBAPI connection object used by the underlying driver in use. The object will have all the same behavior as the real DBAPI connection, except that its
close()
method will result in the connection being returned to the pool, rather than being closed for real.This method provides direct DBAPI connection access for special situations when the API provided by
_engine.Connection
is not needed. When a_engine.Connection
object is already present, the DBAPI connection is available using the_engine.Connection.connection
accessor.See also
dbapi_connections
-
run_callable
(callable_, *args, **kwargs)¶ Given a callable object or function, execute it, passing a
_engine.Connection
as the first argument.The given *args and **kwargs are passed subsequent to the
_engine.Connection
argument.This function, along with
_engine.Connection.run_callable()
, allows a function to be run with a_engine.Connection
or_engine.Engine
object without the need to know which one is being dealt with.
-
scalar
(statement, *multiparams, **params)¶ Executes and returns the first column of the first row.
The underlying cursor is closed after execution.
-
schema_for_object
= <sqlalchemy.sql.schema._SchemaTranslateMap object>¶ Return the “.schema” attribute for an object.
Used for
_schema.Table
,Sequence
and similar objects, and takes into account the :paramref:`.Connection.execution_options.schema_translate_map` parameter.New in version 1.1.
See also
schema_translating
-
table_names
(schema=None, connection=None)¶ Return a list of all table names available in the database.
- Parameters
schema – Optional, retrieve names from a non-default schema.
connection – Optional, use a specified connection. Default is the
contextual_connect
for thisEngine
.
-
transaction
(callable_, *args, **kwargs)¶ Execute the given function within a transaction boundary.
The function is passed a
_engine.Connection
newly procured from_engine.Engine.contextual_connect()
as the first argument, followed by the given *args and **kwargs.e.g.:
def do_something(conn, x, y): conn.execute("some statement", {'x':x, 'y':y}) engine.transaction(do_something, 5, 10)
The operations inside the function are all invoked within the context of a single
Transaction
. Upon success, the transaction is committed. If an exception is raised, the transaction is rolled back before propagating the exception.Note
The
transaction()
method is superseded by the usage of the Pythonwith:
statement, which can be used with_engine.Engine.begin()
:with engine.begin() as conn: conn.execute("some statement", {'x':5, 'y':10})
See also
_engine.Engine.begin()
- engine-level transactional context_engine.Connection.transaction()
- connection-level version of_engine.Engine.transaction()
-
update_execution_options
(**opt)¶ Update the default execution_options dictionary of this
_engine.Engine
.The given keys/values in **opt are added to the default execution options that will be used for all connections. The initial contents of this dictionary can be sent via the
execution_options
parameter to_sa.create_engine()
.See also
_engine.Connection.execution_options()
_engine.Engine.execution_options()
-
sqlalchemy.orm¶
Functional constructs for ORM configuration.
See the SQLAlchemy object relational tutorial and mapper configuration documentation for an overview of how this module is used.
-
class
Session
(bind=None, autoflush=True, expire_on_commit=True, _enable_transaction_accounting=True, autocommit=False, twophase=False, weak_identity_map=None, binds=None, extension=None, enable_baked_queries=True, info=None, query_cls=None)¶ Manages persistence operations for ORM-mapped objects.
The Session’s usage paradigm is described at /orm/session.
-
add
(instance, _warn=True)¶ Place an object in the
Session
.Its state will be persisted to the database on the next flush operation.
Repeated calls to
add()
will be ignored. The opposite ofadd()
isexpunge()
.
-
add_all
(instances)¶ Add the given collection of instances to this
Session
.
-
begin
(subtransactions=False, nested=False)¶ Begin a transaction on this
Session
.Warning
The
Session.begin()
method is part of a larger pattern of use with theSession
known as autocommit mode. This is essentially a legacy mode of use and is not necessary for new applications. TheSession
normally handles the work of “begin” transparently, which in turn relies upon the Python DBAPI to transparently “begin” transactions; there is no need to explicitly begin transactions when using modernSession
programming patterns. In its default mode ofautocommit=False
, theSession
does all of its work within the context of a transaction, so as soon as you callSession.commit()
, the next transaction is implicitly started when the next database operation is invoked. See session_autocommit for further background.The method will raise an error if this
Session
is already inside of a transaction, unless :paramref:`~.Session.begin.subtransactions` or :paramref:`~.Session.begin.nested` are specified. A “subtransaction” is essentially a code embedding pattern that does not affect the transactional state of the database connection unless a rollback is emitted, in which case the whole transaction is rolled back. For documentation on subtransactions, please see session_subtransactions.- Parameters
subtransactions – if True, indicates that this
begin()
can create a “subtransaction”.nested – if True, begins a SAVEPOINT transaction and is equivalent to calling
begin_nested()
. For documentation on SAVEPOINT transactions, please see session_begin_nested.
- Returns
the
SessionTransaction
object. Note thatSessionTransaction
acts as a Python context manager, allowingSession.begin()
to be used in a “with” block. See session_autocommit for an example.
-
begin_nested
()¶ Begin a “nested” transaction on this Session, e.g. SAVEPOINT.
The target database(s) and associated drivers must support SQL SAVEPOINT for this method to function correctly.
For documentation on SAVEPOINT transactions, please see session_begin_nested.
- Returns
the
SessionTransaction
object. Note thatSessionTransaction
acts as a context manager, allowingSession.begin_nested()
to be used in a “with” block. See session_begin_nested for a usage example.
See also
session_begin_nested
pysqlite_serializable - special workarounds required with the SQLite driver in order for SAVEPOINT to work correctly.
-
bind_mapper
(mapper, bind)¶ Associate a
_orm.Mapper
or arbitrary Python class with a “bind”, e.g. an_engine.Engine
or_engine.Connection
.The given entity is added to a lookup used by the
Session.get_bind()
method.- Parameters
mapper – a
_orm.Mapper
object, or an instance of a mapped class, or any Python class that is the base of a set of mapped classes.bind – an
_engine.Engine
or_engine.Connection
object.
-
bind_table
(table, bind)¶ Associate a
_schema.Table
with a “bind”, e.g. an_engine.Engine
or_engine.Connection
.The given
_schema.Table
is added to a lookup used by theSession.get_bind()
method.- Parameters
table – a
_schema.Table
object, which is typically the target of an ORM mapping, or is present within a selectable that is mapped.bind – an
_engine.Engine
or_engine.Connection
object.
-
bulk_insert_mappings
(mapper, mappings, return_defaults=False, render_nulls=False)¶ Perform a bulk insert of the given list of mapping dictionaries.
The bulk insert feature allows plain Python dictionaries to be used as the source of simple INSERT operations which can be more easily grouped together into higher performing “executemany” operations. Using dictionaries, there is no “history” or session state management features in use, reducing latency when inserting large numbers of simple rows.
The values within the dictionaries as given are typically passed without modification into Core
_expression.Insert()
constructs, after organizing the values within them across the tables to which the given mapper is mapped.New in version 1.0.0.
Warning
The bulk insert feature allows for a lower-latency INSERT of rows at the expense of most other unit-of-work features. Features such as object management, relationship handling, and SQL clause support are silently omitted in favor of raw INSERT of records.
Please read the list of caveats at bulk_operations_caveats before using this method, and fully test and confirm the functionality of all code developed using these systems.
- Parameters
mapper – a mapped class, or the actual
_orm.Mapper
object, representing the single kind of object represented within the mapping list.mappings – a sequence of dictionaries, each one containing the state of the mapped row to be inserted, in terms of the attribute names on the mapped class. If the mapping refers to multiple tables, such as a joined-inheritance mapping, each dictionary must contain all keys to be populated into all tables.
return_defaults – when True, rows that are missing values which generate defaults, namely integer primary key defaults and sequences, will be inserted one at a time, so that the primary key value is available. In particular this will allow joined-inheritance and other multi-table mappings to insert correctly without the need to provide primary key values ahead of time; however, :paramref:`.Session.bulk_insert_mappings.return_defaults` greatly reduces the performance gains of the method overall. If the rows to be inserted only refer to a single table, then there is no reason this flag should be set as the returned default information is not used.
render_nulls –
When True, a value of
None
will result in a NULL value being included in the INSERT statement, rather than the column being omitted from the INSERT. This allows all the rows being INSERTed to have the identical set of columns which allows the full set of rows to be batched to the DBAPI. Normally, each column-set that contains a different combination of NULL values than the previous row must omit a different series of columns from the rendered INSERT statement, which means it must be emitted as a separate statement. By passing this flag, the full set of rows are guaranteed to be batchable into one batch; the cost however is that server-side defaults which are invoked by an omitted column will be skipped, so care must be taken to ensure that these are not necessary.Warning
When this flag is set, server side default SQL values will not be invoked for those columns that are inserted as NULL; the NULL value will be sent explicitly. Care must be taken to ensure that no server-side default functions need to be invoked for the operation as a whole.
New in version 1.1.
-
bulk_save_objects
(objects, return_defaults=False, update_changed_only=True, preserve_order=True)¶ Perform a bulk save of the given list of objects.
The bulk save feature allows mapped objects to be used as the source of simple INSERT and UPDATE operations which can be more easily grouped together into higher performing “executemany” operations; the extraction of data from the objects is also performed using a lower-latency process that ignores whether or not attributes have actually been modified in the case of UPDATEs, and also ignores SQL expressions.
The objects as given are not added to the session and no additional state is established on them, unless the
return_defaults
flag is also set, in which case primary key attributes and server-side default values will be populated.New in version 1.0.0.
Warning
The bulk save feature allows for a lower-latency INSERT/UPDATE of rows at the expense of most other unit-of-work features. Features such as object management, relationship handling, and SQL clause support are silently omitted in favor of raw INSERT/UPDATES of records.
Please read the list of caveats at bulk_operations_caveats before using this method, and fully test and confirm the functionality of all code developed using these systems.
- Parameters
objects –
a sequence of mapped object instances. The mapped objects are persisted as is, and are not associated with the
Session
afterwards.For each object, whether the object is sent as an INSERT or an UPDATE is dependent on the same rules used by the
Session
in traditional operation; if the object has theInstanceState.key
attribute set, then the object is assumed to be “detached” and will result in an UPDATE. Otherwise, an INSERT is used.In the case of an UPDATE, statements are grouped based on which attributes have changed, and are thus to be the subject of each SET clause. If
update_changed_only
is False, then all attributes present within each object are applied to the UPDATE statement, which may help in allowing the statements to be grouped together into a larger executemany(), and will also reduce the overhead of checking history on attributes.return_defaults – when True, rows that are missing values which generate defaults, namely integer primary key defaults and sequences, will be inserted one at a time, so that the primary key value is available. In particular this will allow joined-inheritance and other multi-table mappings to insert correctly without the need to provide primary key values ahead of time; however, :paramref:`.Session.bulk_save_objects.return_defaults` greatly reduces the performance gains of the method overall.
update_changed_only – when True, UPDATE statements are rendered based on those attributes in each state that have logged changes. When False, all attributes present are rendered into the SET clause with the exception of primary key attributes.
preserve_order –
when True, the order of inserts and updates matches exactly the order in which the objects are given. When False, common types of objects are grouped into inserts and updates, to allow for more batching opportunities.
New in version 1.3.
-
bulk_update_mappings
(mapper, mappings)¶ Perform a bulk update of the given list of mapping dictionaries.
The bulk update feature allows plain Python dictionaries to be used as the source of simple UPDATE operations which can be more easily grouped together into higher performing “executemany” operations. Using dictionaries, there is no “history” or session state management features in use, reducing latency when updating large numbers of simple rows.
New in version 1.0.0.
Warning
The bulk update feature allows for a lower-latency UPDATE of rows at the expense of most other unit-of-work features. Features such as object management, relationship handling, and SQL clause support are silently omitted in favor of raw UPDATES of records.
Please read the list of caveats at bulk_operations_caveats before using this method, and fully test and confirm the functionality of all code developed using these systems.
- Parameters
mapper – a mapped class, or the actual
_orm.Mapper
object, representing the single kind of object represented within the mapping list.mappings – a sequence of dictionaries, each one containing the state of the mapped row to be updated, in terms of the attribute names on the mapped class. If the mapping refers to multiple tables, such as a joined-inheritance mapping, each dictionary may contain keys corresponding to all tables. All those keys which are present and are not part of the primary key are applied to the SET clause of the UPDATE statement; the primary key values, which are required, are applied to the WHERE clause.
-
close
()¶ Close this Session.
This clears all items and ends any transaction in progress.
If this session were created with
autocommit=False
, a new transaction is immediately begun. Note that this new transaction does not use any connection resources until they are first needed.
-
commit
()¶ Flush pending changes and commit the current transaction.
If no transaction is in progress, this method raises an
InvalidRequestError
.By default, the
Session
also expires all database loaded state on all ORM-managed attributes after transaction commit. This so that subsequent operations load the most recent data from the database. This behavior can be disabled using theexpire_on_commit=False
option tosessionmaker
or theSession
constructor.If a subtransaction is in effect (which occurs when begin() is called multiple times), the subtransaction will be closed, and the next call to
commit()
will operate on the enclosing transaction.When using the
Session
in its default mode ofautocommit=False
, a new transaction will be begun immediately after the commit, but note that the newly begun transaction does not use any connection resources until the first SQL is actually emitted.See also
session_committing
-
connection
(mapper=None, clause=None, bind=None, close_with_result=False, execution_options=None, **kw)¶ Return a
_engine.Connection
object corresponding to thisSession
object’s transactional state.If this
Session
is configured withautocommit=False
, either the_engine.Connection
corresponding to the current transaction is returned, or if no transaction is in progress, a new one is begun and the_engine.Connection
returned (note that no transactional state is established with the DBAPI until the first SQL statement is emitted).Alternatively, if this
Session
is configured withautocommit=True
, an ad-hoc_engine.Connection
is returned using_engine.Engine.connect()
on the underlying_engine.Engine
.Ambiguity in multi-bind or unbound
Session
objects can be resolved through any of the optional keyword arguments. This ultimately makes usage of theget_bind()
method for resolution.- Parameters
bind – Optional
_engine.Engine
to be used as the bind. If this engine is already involved in an ongoing transaction, that connection will be used. This argument takes precedence overmapper
,clause
.mapper – Optional
mapper()
mapped class, used to identify the appropriate bind. This argument takes precedence overclause
.clause – A
_expression.ClauseElement
(i.e._expression.select()
,_expression.text()
, etc.) which will be used to locate a bind, if a bind cannot otherwise be identified.close_with_result – Passed to
_engine.Engine.connect()
, indicating the_engine.Connection
should be considered “single use”, automatically closing when the first result set is closed. This flag only has an effect if thisSession
is configured withautocommit=True
and does not already have a transaction in progress.execution_options –
a dictionary of execution options that will be passed to
_engine.Connection.execution_options()
, when the connection is first procured only. If the connection is already present within theSession
, a warning is emitted and the arguments are ignored.New in version 0.9.9.
See also
session_transaction_isolation
**kw – Additional keyword arguments are sent to
get_bind()
, allowing additional arguments to be passed to custom implementations ofget_bind()
.
-
delete
(instance)¶ Mark an instance as deleted.
The database delete operation occurs upon
flush()
.
-
property
deleted
¶ The set of all instances marked as ‘deleted’ within this
Session
-
property
dirty
¶ The set of all persistent instances considered dirty.
E.g.:
some_mapped_object in session.dirty
Instances are considered dirty when they were modified but not deleted.
Note that this ‘dirty’ calculation is ‘optimistic’; most attribute-setting or collection modification operations will mark an instance as ‘dirty’ and place it in this set, even if there is no net change to the attribute’s value. At flush time, the value of each attribute is compared to its previously saved value, and if there’s no net change, no SQL operation will occur (this is a more expensive operation so it’s only done at flush time).
To check if an instance has actionable net changes to its attributes, use the
Session.is_modified()
method.
-
enable_relationship_loading
(obj)¶ Associate an object with this
Session
for related object loading.Warning
enable_relationship_loading()
exists to serve special use cases and is not recommended for general use.Accesses of attributes mapped with
_orm.relationship()
will attempt to load a value from the database using thisSession
as the source of connectivity. The values will be loaded based on foreign key and primary key values present on this object - if not present, then those relationships will be unavailable.The object will be attached to this session, but will not participate in any persistence operations; its state for almost all purposes will remain either “transient” or “detached”, except for the case of relationship loading.
Also note that backrefs will often not work as expected. Altering a relationship-bound attribute on the target object may not fire off a backref event, if the effective value is what was already loaded from a foreign-key-holding value.
The
Session.enable_relationship_loading()
method is similar to theload_on_pending
flag on_orm.relationship()
. Unlike that flag,Session.enable_relationship_loading()
allows an object to remain transient while still being able to load related items.To make a transient object associated with a
Session
viaSession.enable_relationship_loading()
pending, add it to theSession
usingSession.add()
normally. If the object instead represents an existing identity in the database, it should be merged usingSession.merge()
.Session.enable_relationship_loading()
does not improve behavior when the ORM is used normally - object references should be constructed at the object level, not at the foreign key level, so that they are present in an ordinary way before flush() proceeds. This method is not intended for general use.See also
:paramref:`_orm.relationship.load_on_pending` - this flag allows per-relationship loading of many-to-ones on items that are pending.
make_transient_to_detached()
- allows for an object to be added to aSession
without SQL emitted, which then will unexpire attributes on access.
-
execute
(clause, params=None, mapper=None, bind=None, **kw)¶ Execute a SQL expression construct or string statement within the current transaction.
Returns a
_engine.ResultProxy
representing results of the statement execution, in the same manner as that of an_engine.Engine
or_engine.Connection
.E.g.:
result = session.execute( user_table.select().where(user_table.c.id == 5) )
execute()
accepts any executable clause construct, such as_expression.select()
,_expression.insert()
,_expression.update()
,_expression.delete()
, and_expression.text()
. Plain SQL strings can be passed as well, which in the case ofSession.execute()
only will be interpreted the same as if it were passed via a_expression.text()
construct. That is, the following usage:result = session.execute( "SELECT * FROM user WHERE id=:param", {"param":5} )
is equivalent to:
from sqlalchemy import text result = session.execute( text("SELECT * FROM user WHERE id=:param"), {"param":5} )
The second positional argument to
Session.execute()
is an optional parameter set. Similar to that of_engine.Connection.execute()
, whether this is passed as a single dictionary, or a sequence of dictionaries, determines whether the DBAPI cursor’sexecute()
orexecutemany()
is used to execute the statement. An INSERT construct may be invoked for a single row:result = session.execute( users.insert(), {"id": 7, "name": "somename"})
or for multiple rows:
result = session.execute(users.insert(), [ {"id": 7, "name": "somename7"}, {"id": 8, "name": "somename8"}, {"id": 9, "name": "somename9"} ])
The statement is executed within the current transactional context of this
Session
. The_engine.Connection
which is used to execute the statement can also be acquired directly by calling theSession.connection()
method. Both methods use a rule-based resolution scheme in order to determine the_engine.Connection
, which in the average case is derived directly from the “bind” of theSession
itself, and in other cases can be based on themapper()
and_schema.Table
objects passed to the method; see the documentation forSession.get_bind()
for a full description of this scheme.The
Session.execute()
method does not invoke autoflush.The
_engine.ResultProxy
returned by theSession.execute()
method is returned with the “close_with_result” flag set to true; the significance of this flag is that if thisSession
is autocommitting and does not have a transaction-dedicated_engine.Connection
available, a temporary_engine.Connection
is established for the statement execution, which is closed (meaning, returned to the connection pool) when the_engine.ResultProxy
has consumed all available data. This applies only when theSession
is configured with autocommit=True and no transaction has been started.- Parameters
clause – An executable statement (i.e. an
Executable
expression such as_expression.select()
) or string SQL statement to be executed.params – Optional dictionary, or list of dictionaries, containing bound parameter values. If a single dictionary, single-row execution occurs; if a list of dictionaries, an “executemany” will be invoked. The keys in each dictionary must correspond to parameter names present in the statement.
mapper – Optional
mapper()
or mapped class, used to identify the appropriate bind. This argument takes precedence overclause
when locating a bind. SeeSession.get_bind()
for more details.bind – Optional
_engine.Engine
to be used as the bind. If this engine is already involved in an ongoing transaction, that connection will be used. This argument takes precedence overmapper
andclause
when locating a bind.**kw – Additional keyword arguments are sent to
Session.get_bind()
to allow extensibility of “bind” schemes.
See also
sqlexpression_toplevel - Tutorial on using Core SQL constructs.
connections_toplevel - Further information on direct statement execution.
_engine.Connection.execute()
- core level statement execution method, which isSession.execute()
ultimately uses in order to execute the statement.
-
expire
(instance, attribute_names=None)¶ Expire the attributes on an instance.
Marks the attributes of an instance as out of date. When an expired attribute is next accessed, a query will be issued to the
Session
object’s current transactional context in order to load all expired attributes for the given instance. Note that a highly isolated transaction will return the same values as were previously read in that same transaction, regardless of changes in database state outside of that transaction.To expire all objects in the
Session
simultaneously, useSession.expire_all()
.The
Session
object’s default behavior is to expire all state whenever theSession.rollback()
orSession.commit()
methods are called, so that new state can be loaded for the new transaction. For this reason, callingSession.expire()
only makes sense for the specific case that a non-ORM SQL statement was emitted in the current transaction.- Parameters
instance – The instance to be refreshed.
attribute_names – optional list of string attribute names indicating a subset of attributes to be expired.
See also
session_expire - introductory material
_orm.Query.populate_existing()
-
expire_all
()¶ Expires all persistent instances within this Session.
When any attributes on a persistent instance is next accessed, a query will be issued using the
Session
object’s current transactional context in order to load all expired attributes for the given instance. Note that a highly isolated transaction will return the same values as were previously read in that same transaction, regardless of changes in database state outside of that transaction.To expire individual objects and individual attributes on those objects, use
Session.expire()
.The
Session
object’s default behavior is to expire all state whenever theSession.rollback()
orSession.commit()
methods are called, so that new state can be loaded for the new transaction. For this reason, callingSession.expire_all()
should not be needed when autocommit isFalse
, assuming the transaction is isolated.See also
session_expire - introductory material
_orm.Query.populate_existing()
-
expunge
(instance)¶ Remove the instance from this
Session
.This will free all internal references to the instance. Cascading will be applied according to the expunge cascade rule.
-
expunge_all
()¶ Remove all object instances from this
Session
.This is equivalent to calling
expunge(obj)
on all objects in thisSession
.
-
flush
(objects=None)¶ Flush all the object changes to the database.
Writes out all pending object creations, deletions and modifications to the database as INSERTs, DELETEs, UPDATEs, etc. Operations are automatically ordered by the Session’s unit of work dependency solver.
Database operations will be issued in the current transactional context and do not affect the state of the transaction, unless an error occurs, in which case the entire transaction is rolled back. You may flush() as often as you like within a transaction to move changes from Python to the database’s transaction buffer.
For
autocommit
Sessions with no active manual transaction, flush() will create a transaction on the fly that surrounds the entire set of operations into the flush.- Parameters
objects –
Optional; restricts the flush operation to operate only on elements that are in the given collection.
This feature is for an extremely narrow set of use cases where particular objects may need to be operated upon before the full flush() occurs. It is not intended for general use.
-
get_bind
(mapper=None, clause=None)¶ Return a “bind” to which this
Session
is bound.The “bind” is usually an instance of
_engine.Engine
, except in the case where theSession
has been explicitly bound directly to a_engine.Connection
.For a multiply-bound or unbound
Session
, themapper
orclause
arguments are used to determine the appropriate bind to return.Note that the “mapper” argument is usually present when
Session.get_bind()
is called via an ORM operation such as aSession.query()
, each individual INSERT/UPDATE/DELETE operation within aSession.flush()
, call, etc.The order of resolution is:
if mapper given and :paramref:`.Session.binds` is present, locate a bind based first on the mapper in use, then on the mapped class in use, then on any base classes that are present in the
__mro__
of the mapped class, from more specific superclasses to more general.if clause given and
Session.binds
is present, locate a bind based on_schema.Table
objects found in the given clause present inSession.binds
.if
Session.binds
is present, return that.if clause given, attempt to return a bind linked to the
_schema.MetaData
ultimately associated with the clause.if mapper given, attempt to return a bind linked to the
_schema.MetaData
ultimately associated with the_schema.Table
or other selectable to which the mapper is mapped.No bind can be found,
UnboundExecutionError
is raised.
Note that the
Session.get_bind()
method can be overridden on a user-defined subclass ofSession
to provide any kind of bind resolution scheme. See the example at session_custom_partitioning.- Parameters
mapper – Optional
mapper()
mapped class or instance of_orm.Mapper
. The bind can be derived from a_orm.Mapper
first by consulting the “binds” map associated with thisSession
, and secondly by consulting the_schema.MetaData
associated with the_schema.Table
to which the_orm.Mapper
is mapped for a bind.clause – A
_expression.ClauseElement
(i.e._expression.select()
,_expression.text()
, etc.). If themapper
argument is not present or could not produce a bind, the given expression construct will be searched for a bound element, typically a_schema.Table
associated with bound_schema.MetaData
.
-
identity_map
= None¶ A mapping of object identities to objects themselves.
Iterating through
Session.identity_map.values()
provides access to the full set of persistent objects (i.e., those that have row identity) currently in the session.See also
identity_key()
- helper function to produce the keys used in this dictionary.
-
info
¶ A user-modifiable dictionary.
The initial value of this dictionary can be populated using the
info
argument to theSession
constructor orsessionmaker
constructor or factory methods. The dictionary here is always local to thisSession
and can be modified independently of all otherSession
objects.New in version 0.9.0.
-
invalidate
()¶ Close this Session, using connection invalidation.
This is a variant of
Session.close()
that will additionally ensure that the_engine.Connection.invalidate()
method will be called on all_engine.Connection
objects. This can be called when the database is known to be in a state where the connections are no longer safe to be used.E.g.:
try: sess = Session() sess.add(User()) sess.commit() except gevent.Timeout: sess.invalidate() raise except: sess.rollback() raise
This clears all items and ends any transaction in progress.
If this session were created with
autocommit=False
, a new transaction is immediately begun. Note that this new transaction does not use any connection resources until they are first needed.New in version 0.9.9.
-
property
is_active
¶ True if this
Session
is in “transaction mode” and is not in “partial rollback” state.The
Session
in its default mode ofautocommit=False
is essentially always in “transaction mode”, in that aSessionTransaction
is associated with it as soon as it is instantiated. ThisSessionTransaction
is immediately replaced with a new one as soon as it is ended, due to a rollback, commit, or close operation.“Transaction mode” does not indicate whether or not actual database connection resources are in use; the
SessionTransaction
object coordinates among zero or more actual database transactions, and starts out with none, accumulating individual DBAPI connections as different data sources are used within its scope. The best way to track when a particularSession
has actually begun to use DBAPI resources is to implement a listener using theSessionEvents.after_begin()
method, which will deliver both theSession
as well as the target_engine.Connection
to a user-defined event listener.The “partial rollback” state refers to when an “inner” transaction, typically used during a flush, encounters an error and emits a rollback of the DBAPI connection. At this point, the
Session
is in “partial rollback” and awaits for the user to callSession.rollback()
, in order to close out the transaction stack. It is in this “partial rollback” period that theis_active
flag returns False. After the call toSession.rollback()
, theSessionTransaction
is replaced with a new one andis_active
returnsTrue
again.When a
Session
is used inautocommit=True
mode, theSessionTransaction
is only instantiated within the scope of a flush call, or whenSession.begin()
is called. Sois_active
will always beFalse
outside of a flush orSession.begin()
block in this mode, and will beTrue
within theSession.begin()
block as long as it doesn’t enter “partial rollback” state.From all the above, it follows that the only purpose to this flag is for application frameworks that wish to detect if a “rollback” is necessary within a generic error handling routine, for
Session
objects that would otherwise be in “partial rollback” mode. In a typical integration case, this is also not necessary as it is standard practice to emitSession.rollback()
unconditionally within the outermost exception catch.To track the transactional state of a
Session
fully, use event listeners, primarily theSessionEvents.after_begin()
,SessionEvents.after_commit()
,SessionEvents.after_rollback()
and related events.
-
is_modified
(instance, include_collections=True, passive=None)¶ Return
True
if the given instance has locally modified attributes.This method retrieves the history for each instrumented attribute on the instance and performs a comparison of the current value to its previously committed value, if any.
It is in effect a more expensive and accurate version of checking for the given instance in the
Session.dirty
collection; a full test for each attribute’s net “dirty” status is performed.E.g.:
return session.is_modified(someobject)
A few caveats to this method apply:
Instances present in the
Session.dirty
collection may reportFalse
when tested with this method. This is because the object may have received change events via attribute mutation, thus placing it inSession.dirty
, but ultimately the state is the same as that loaded from the database, resulting in no net change here.Scalar attributes may not have recorded the previously set value when a new value was applied, if the attribute was not loaded, or was expired, at the time the new value was received - in these cases, the attribute is assumed to have a change, even if there is ultimately no net change against its database value. SQLAlchemy in most cases does not need the “old” value when a set event occurs, so it skips the expense of a SQL call if the old value isn’t present, based on the assumption that an UPDATE of the scalar value is usually needed, and in those few cases where it isn’t, is less expensive on average than issuing a defensive SELECT.
The “old” value is fetched unconditionally upon set only if the attribute container has the
active_history
flag set toTrue
. This flag is set typically for primary key attributes and scalar object references that are not a simple many-to-one. To set this flag for any arbitrary mapped column, use theactive_history
argument withcolumn_property()
.
- Parameters
instance – mapped instance to be tested for pending changes.
include_collections – Indicates if multivalued collections should be included in the operation. Setting this to
False
is a way to detect only local-column based properties (i.e. scalar columns or many-to-one foreign keys) that would result in an UPDATE for this instance upon flush.passive –
not used
Deprecated since version 0.8: The :paramref:`.Session.is_modified.passive` flag is deprecated and will be removed in a future release. The flag is no longer used and is ignored.
-
merge
(instance, load=True)¶ Copy the state of a given instance into a corresponding instance within this
Session
.Session.merge()
examines the primary key attributes of the source instance, and attempts to reconcile it with an instance of the same primary key in the session. If not found locally, it attempts to load the object from the database based on primary key, and if none can be located, creates a new instance. The state of each attribute on the source instance is then copied to the target instance. The resulting target instance is then returned by the method; the original source instance is left unmodified, and un-associated with theSession
if not already.This operation cascades to associated instances if the association is mapped with
cascade="merge"
.See unitofwork_merging for a detailed discussion of merging.
Changed in version 1.1: -
Session.merge()
will now reconcile pending objects with overlapping primary keys in the same way as persistent. See change_3601 for discussion.- Parameters
instance – Instance to be merged.
load –
Boolean, when False,
merge()
switches into a “high performance” mode which causes it to forego emitting history events as well as all database access. This flag is used for cases such as transferring graphs of objects into aSession
from a second level cache, or to transfer just-loaded objects into theSession
owned by a worker thread or process without re-querying the database.The
load=False
use case adds the caveat that the given object has to be in a “clean” state, that is, has no pending changes to be flushed - even if the incoming object is detached from anySession
. This is so that when the merge operation populates local attributes and cascades to related objects and collections, the values can be “stamped” onto the target object as is, without generating any history or attribute events, and without the need to reconcile the incoming data with any existing related objects or collections that might not be loaded. The resulting objects fromload=False
are always produced as “clean”, so it is only appropriate that the given objects should be “clean” as well, else this suggests a mis-use of the method.
See also
make_transient_to_detached()
- provides for an alternative means of “merging” a single object into theSession
-
property
new
¶ The set of all instances marked as ‘new’ within this
Session
.
-
property
no_autoflush
¶ Return a context manager that disables autoflush.
e.g.:
with session.no_autoflush: some_object = SomeClass() session.add(some_object) # won't autoflush some_object.related_thing = session.query(SomeRelated).first()
Operations that proceed within the
with:
block will not be subject to flushes occurring upon query access. This is useful when initializing a series of objects which involve existing database queries, where the uncompleted object should not yet be flushed.
-
prepare
()¶ Prepare the current transaction in progress for two phase commit.
If no transaction is in progress, this method raises an
InvalidRequestError
.Only root transactions of two phase sessions can be prepared. If the current transaction is not such, an
InvalidRequestError
is raised.
-
prune
()¶ Remove unreferenced instances cached in the identity map.
Deprecated since version 0.7: The
Session.prune()
method is deprecated along with :paramref:`.Session.weak_identity_map`. This method will be removed in a future release.Note that this method is only meaningful if “weak_identity_map” is set to False. The default weak identity map is self-pruning.
Removes any object in this Session’s identity map that is not referenced in user code, modified, new or scheduled for deletion. Returns the number of objects pruned.
-
refresh
(instance, attribute_names=None, with_for_update=None, lockmode=None)¶ Expire and refresh the attributes on the given instance.
A query will be issued to the database and all attributes will be refreshed with their current database value.
Lazy-loaded relational attributes will remain lazily loaded, so that the instance-wide refresh operation will be followed immediately by the lazy load of that attribute.
Eagerly-loaded relational attributes will eagerly load within the single refresh operation.
Note that a highly isolated transaction will return the same values as were previously read in that same transaction, regardless of changes in database state outside of that transaction - usage of
refresh()
usually only makes sense if non-ORM SQL statement were emitted in the ongoing transaction, or if autocommit mode is turned on.- Parameters
attribute_names – optional. An iterable collection of string attribute names indicating a subset of attributes to be refreshed.
with_for_update –
optional boolean
True
indicating FOR UPDATE should be used, or may be a dictionary containing flags to indicate a more specific set of FOR UPDATE flags for the SELECT; flags should match the parameters of_query.Query.with_for_update()
. Supersedes the :paramref:`.Session.refresh.lockmode` parameter.New in version 1.2.
lockmode – Passed to the
Query
as used bywith_lockmode()
. Superseded by :paramref:`.Session.refresh.with_for_update`.
See also
session_expire - introductory material
_orm.Query.populate_existing()
-
rollback
()¶ Rollback the current transaction in progress.
If no transaction is in progress, this method is a pass-through.
This method rolls back the current transaction or nested transaction regardless of subtransactions being in effect. All subtransactions up to the first real transaction are closed. Subtransactions occur when
begin()
is called multiple times.See also
session_rollback
-
scalar
(clause, params=None, mapper=None, bind=None, **kw)¶ Like
execute()
but return a scalar result.
-
transaction
= None¶ The current active or inactive
SessionTransaction
.
-
Flask¶
Flask library reference