Recall from the section When do I construct a Session, when do I commit it, and when do I close it?, the concept of
“session scopes” was introduced, with an emphasis on web applications
and the practice of linking the scope of a Session
with that
of a web request. Most modern web frameworks include integration tools
so that the scope of the Session
can be managed automatically,
and these tools should be used as they are available.
SQLAlchemy includes its own helper object, which helps with the establishment
of user-defined Session
scopes. It is also used by third-party
integration systems to help construct their integration schemes.
The object is the scoped_session
object, and it represents a
registry of Session
objects. If you’re not familiar with the
registry pattern, a good introduction can be found in Patterns of Enterprise
Architecture.
Note
The scoped_session
object is a very popular and useful object
used by many SQLAlchemy applications. However, it is important to note
that it presents only one approach to the issue of Session
management. If you’re new to SQLAlchemy, and especially if the
term “thread-local variable” seems strange to you, we recommend that
if possible you familiarize first with an off-the-shelf integration
system such as Flask-SQLAlchemy
or zope.sqlalchemy.
A scoped_session
is constructed by calling it, passing it a
factory which can create new Session
objects. A factory
is just something that produces a new object when called, and in the
case of Session
, the most common factory is the sessionmaker
,
introduced earlier in this section. Below we illustrate this usage:
>>> from sqlalchemy.orm import scoped_session
>>> from sqlalchemy.orm import sessionmaker
>>> session_factory = sessionmaker(bind=some_engine)
>>> Session = scoped_session(session_factory)
The scoped_session
object we’ve created will now call upon the
sessionmaker
when we “call” the registry:
>>> some_session = Session()
Above, some_session
is an instance of Session
, which we
can now use to talk to the database. This same Session
is also
present within the scoped_session
registry we’ve created. If
we call upon the registry a second time, we get back the same Session
:
>>> some_other_session = Session()
>>> some_session is some_other_session
True
This pattern allows disparate sections of the application to call upon a global
scoped_session
, so that all those areas may share the same session
without the need to pass it explicitly. The Session
we’ve established
in our registry will remain, until we explicitly tell our registry to dispose of it,
by calling scoped_session.remove()
:
>>> Session.remove()
The scoped_session.remove()
method first calls Session.close()
on
the current Session
, which has the effect of releasing any connection/transactional
resources owned by the Session
first, then discarding the Session
itself. “Releasing” here means that connections are returned to their connection pool and any transactional state is rolled back, ultimately using the rollback()
method of the underlying DBAPI connection.
At this point, the scoped_session
object is “empty”, and will create
a new Session
when called again. As illustrated below, this
is not the same Session
we had before:
>>> new_session = Session()
>>> new_session is some_session
False
The above series of steps illustrates the idea of the “registry” pattern in a nutshell. With that basic idea in hand, we can discuss some of the details of how this pattern proceeds.
The job of the scoped_session
is simple; hold onto a Session
for all who ask for it. As a means of producing more transparent access to this
Session
, the scoped_session
also includes proxy behavior,
meaning that the registry itself can be treated just like a Session
directly; when methods are called on this object, they are proxied to the
underlying Session
being maintained by the registry:
Session = scoped_session(some_factory)
# equivalent to:
#
# session = Session()
# print(session.query(MyClass).all())
#
print(Session.query(MyClass).all())
The above code accomplishes the same task as that of acquiring the current
Session
by calling upon the registry, then using that Session
.
Users who are familiar with multithreaded programming will note that representing
anything as a global variable is usually a bad idea, as it implies that the
global object will be accessed by many threads concurrently. The Session
object is entirely designed to be used in a non-concurrent fashion, which
in terms of multithreading means “only in one thread at a time”. So our
above example of scoped_session
usage, where the same Session
object is maintained across multiple calls, suggests that some process needs
to be in place such that multiple calls across many threads don’t actually get
a handle to the same session. We call this notion thread local storage,
which means, a special object is used that will maintain a distinct object
per each application thread. Python provides this via the
threading.local()
construct. The scoped_session
object by default uses this object
as storage, so that a single Session
is maintained for all who call
upon the scoped_session
registry, but only within the scope of a single
thread. Callers who call upon the registry in a different thread get a
Session
instance that is local to that other thread.
Using this technique, the scoped_session
provides a quick and relatively
simple (if one is familiar with thread-local storage) way of providing
a single, global object in an application that is safe to be called upon
from multiple threads.
The scoped_session.remove()
method, as always, removes the current
Session
associated with the thread, if any. However, one advantage of the
threading.local()
object is that if the application thread itself ends, the
“storage” for that thread is also garbage collected. So it is in fact “safe” to
use thread local scope with an application that spawns and tears down threads,
without the need to call scoped_session.remove()
. However, the scope
of transactions themselves, i.e. ending them via Session.commit()
or
Session.rollback()
, will usually still be something that must be explicitly
arranged for at the appropriate time, unless the application actually ties the
lifespan of a thread to the lifespan of a transaction.
As discussed in the section When do I construct a Session, when do I commit it, and when do I close it?, a web application
is architected around the concept of a web request, and integrating
such an application with the Session
usually implies that the Session
will be associated with that request. As it turns out, most Python web frameworks,
with notable exceptions such as the asynchronous frameworks Twisted and
Tornado, use threads in a simple way, such that a particular web request is received,
processed, and completed within the scope of a single worker thread. When
the request ends, the worker thread is released to a pool of workers where it
is available to handle another request.
This simple correspondence of web request and thread means that to associate a
Session
with a thread implies it is also associated with the web request
running within that thread, and vice versa, provided that the Session
is
created only after the web request begins and torn down just before the web request ends.
So it is a common practice to use scoped_session
as a quick way
to integrate the Session
with a web application. The sequence
diagram below illustrates this flow:
Web Server Web Framework SQLAlchemy ORM Code
-------------- -------------- ------------------------------
startup -> Web framework # Session registry is established
initializes Session = scoped_session(sessionmaker())
incoming
web request -> web request -> # The registry is *optionally*
starts # called upon explicitly to create
# a Session local to the thread and/or request
Session()
# the Session registry can otherwise
# be used at any time, creating the
# request-local Session() if not present,
# or returning the existing one
Session.query(MyClass) # ...
Session.add(some_object) # ...
# if data was modified, commit the
# transaction
Session.commit()
web request ends -> # the registry is instructed to
# remove the Session
Session.remove()
sends output <-
outgoing web <-
response
Using the above flow, the process of integrating the Session
with the
web application has exactly two requirements:
Create a single scoped_session
registry when the web application
first starts, ensuring that this object is accessible by the rest of the
application.
Ensure that scoped_session.remove()
is called when the web request ends,
usually by integrating with the web framework’s event system to establish
an “on request end” event.
As noted earlier, the above pattern is just one potential way to integrate a Session
with a web framework, one which in particular makes the significant assumption
that the web framework associates web requests with application threads. It is
however strongly recommended that the integration tools provided with the web framework
itself be used, if available, instead of scoped_session
.
In particular, while using a thread local can be convenient, it is preferable that the Session
be
associated directly with the request, rather than with
the current thread. The next section on custom scopes details a more advanced configuration
which can combine the usage of scoped_session
with direct request based scope, or
any kind of scope.
The scoped_session
object’s default behavior of “thread local” scope is only
one of many options on how to “scope” a Session
. A custom scope can be defined
based on any existing system of getting at “the current thing we are working with”.
Suppose a web framework defines a library function get_current_request()
. An application
built using this framework can call this function at any time, and the result will be
some kind of Request
object that represents the current request being processed.
If the Request
object is hashable, then this function can be easily integrated with
scoped_session
to associate the Session
with the request. Below we illustrate
this in conjunction with a hypothetical event marker provided by the web framework
on_request_end
, which allows code to be invoked whenever a request ends:
from my_web_framework import get_current_request, on_request_end
from sqlalchemy.orm import scoped_session, sessionmaker
Session = scoped_session(sessionmaker(bind=some_engine), scopefunc=get_current_request)
@on_request_end
def remove_session(req):
Session.remove()
Above, we instantiate scoped_session
in the usual way, except that we pass
our request-returning function as the “scopefunc”. This instructs scoped_session
to use this function to generate a dictionary key whenever the registry is called upon
to return the current Session
. In this case it is particularly important
that we ensure a reliable “remove” system is implemented, as this dictionary is not
otherwise self-managed.
Object Name | Description |
---|---|
Provides scoped management of |
|
A Registry that can store one or multiple instances of a single class on the basis of a “scope” function. |
|
A |
Provides scoped management of Session
objects.
See Contextual/Thread-local Sessions for a tutorial.
Class signature
class sqlalchemy.orm.scoping.scoped_session
(sqlalchemy.orm.scoping.ScopedSessionMixin
)
sqlalchemy.orm.scoping.scoped_session.
__call__(**kw)¶inherited from the sqlalchemy.orm.scoping.ScopedSessionMixin.__call__
method of ScopedSessionMixin
Return the current Session
, creating it
using the scoped_session.session_factory
if not present.
**kw¶ – Keyword arguments will be passed to the
scoped_session.session_factory
callable, if an existing
Session
is not present. If the Session
is present
and keyword arguments have been passed,
InvalidRequestError
is raised.
sqlalchemy.orm.scoping.scoped_session.
__init__(session_factory, scopefunc=None)¶Construct a new scoped_session
.
session_factory¶ – a factory to create new Session
instances. This is usually, but not necessarily, an instance
of sessionmaker
.
scopefunc¶ – optional function which defines
the current scope. If not passed, the scoped_session
object assumes “thread-local” scope, and will use
a Python threading.local()
in order to maintain the current
Session
. If passed, the function should return
a hashable token; this token will be used as the key in a
dictionary in order to store and retrieve the current
Session
.
sqlalchemy.orm.scoping.scoped_session.
add(instance, _warn=True)¶Place an object in the Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
Its state will be persisted to the database on the next flush operation.
Repeated calls to add()
will be ignored. The opposite of add()
is expunge()
.
sqlalchemy.orm.scoping.scoped_session.
add_all(instances)¶Add the given collection of instances to this Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
sqlalchemy.orm.scoping.scoped_session.
begin(subtransactions=False, nested=False, _subtrans=False)¶Begin a transaction, or nested transaction,
on this Session
, if one is not already begun.
Proxied for the Session
class on behalf of the scoped_session
class.
The Session
object features autobegin behavior,
so that normally it is not necessary to call the
Session.begin()
method explicitly. However, it may be used in order to control
the scope of when the transactional state is begun.
When used to begin the outermost transaction, an error is raised
if this Session
is already inside of a transaction.
nested¶ – if True, begins a SAVEPOINT transaction and is
equivalent to calling Session.begin_nested()
. For
documentation on SAVEPOINT transactions, please see
Using SAVEPOINT.
subtransactions¶ –
if True, indicates that this
Session.begin()
can create a “subtransaction”.
Deprecated since version 1.4: The Session.begin.subtransactions
flag is deprecated and will be removed in SQLAlchemy version 2.0. See the documentation at Migrating from the “subtransaction” pattern for background on a compatible alternative pattern.
the SessionTransaction
object. Note that
SessionTransaction
acts as a Python context manager, allowing Session.begin()
to be used in a “with” block. See Explicit Begin for
an example.
sqlalchemy.orm.scoping.scoped_session.
begin_nested()¶Begin a “nested” transaction on this Session, e.g. SAVEPOINT.
Proxied for the Session
class on behalf of the scoped_session
class.
The target database(s) and associated drivers must support SQL SAVEPOINT for this method to function correctly.
For documentation on SAVEPOINT transactions, please see Using SAVEPOINT.
the SessionTransaction
object. Note that
SessionTransaction
acts as a context manager, allowing
Session.begin_nested()
to be used in a “with” block.
See Using SAVEPOINT for a usage example.
See also
Serializable isolation / Savepoints / Transactional DDL - special workarounds required with the SQLite driver in order for SAVEPOINT to work correctly.
sqlalchemy.orm.scoping.scoped_session.
bulk_insert_mappings(mapper, mappings, return_defaults=False, render_nulls=False)¶Perform a bulk insert of the given list of mapping dictionaries.
Proxied for the Session
class on behalf of the scoped_session
class.
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 sqlalchemy.sql.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 ORM Compatibility / Caveats before using this method, and fully test and confirm the functionality of all code developed using these systems.
mapper¶ – a mapped class, or the actual 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,
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.
sqlalchemy.orm.scoping.scoped_session.
bulk_save_objects(objects, return_defaults=False, update_changed_only=True, preserve_order=True)¶Perform a bulk save of the given list of objects.
Proxied for the Session
class on behalf of the scoped_session
class.
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 ORM Compatibility / Caveats before using this method, and fully test and confirm the functionality of all code developed using these systems.
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 the
InstanceState.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,
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.
sqlalchemy.orm.scoping.scoped_session.
bulk_update_mappings(mapper, mappings)¶Perform a bulk update of the given list of mapping dictionaries.
Proxied for the Session
class on behalf of the scoped_session
class.
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 ORM Compatibility / Caveats before using this method, and fully test and confirm the functionality of all code developed using these systems.
mapper¶ – a mapped class, or the actual 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.
sqlalchemy.orm.scoping.scoped_session.
close()¶Close out the transactional resources and ORM objects used by this
Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
This expunges all ORM objects associated with this
Session
, ends any transaction in progress and
releases any Connection
objects which this
Session
itself has checked out from associated
Engine
objects. The operation then leaves the
Session
in a state which it may be used again.
Tip
The Session.close()
method does not prevent the
Session from being used again. The Session
itself
does not actually have a distinct “closed” state; it merely means
the Session
will release all database connections
and ORM objects.
Changed in version 1.4: The Session.close()
method does not
immediately create a new SessionTransaction
object;
instead, the new SessionTransaction
is created only if
the Session
is used again for a database operation.
See also
Closing - detail on the semantics of
Session.close()
sqlalchemy.orm.scoping.scoped_session.
classmethod close_all()¶Close all sessions in memory.
Proxied for the Session
class on behalf of the scoped_session
class.
Deprecated since version 1.3: The Session.close_all()
method is deprecated and will be removed in a future release. Please refer to close_all_sessions()
.
sqlalchemy.orm.scoping.scoped_session.
commit()¶Flush pending changes and commit the current transaction.
Proxied for the Session
class on behalf of the scoped_session
class.
If no transaction is in progress, the method will first “autobegin” a new transaction and commit.
If 1.x-style use is in effect and there are currently
SAVEPOINTs in progress via Session.begin_nested()
,
the operation will release the current SAVEPOINT but not commit
the outermost database transaction.
If 2.0-style use is in effect via the
Session.future
flag, the outermost database
transaction is committed unconditionally, automatically releasing any
SAVEPOINTs in effect.
When using legacy “autocommit” mode, this method is only valid to call if a transaction is actually in progress, else an error is raised. Similarly, when using legacy “subtransactions”, the method will instead close out the current “subtransaction”, rather than the actual database transaction, if a transaction is in progress.
sqlalchemy.orm.scoping.scoped_session.
configure(**kwargs)¶inherited from the ScopedSessionMixin.configure()
method of ScopedSessionMixin
reconfigure the sessionmaker
used by this
scoped_session
.
sqlalchemy.orm.scoping.scoped_session.
connection(bind_arguments=None, close_with_result=False, execution_options=None, **kw)¶Return a Connection
object corresponding to this
Session
object’s transactional state.
Proxied for the Session
class on behalf of the scoped_session
class.
If this Session
is configured with autocommit=False
,
either the Connection
corresponding to the current
transaction is returned, or if no transaction is in progress, a new
one is begun and the 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 with
autocommit=True
, an ad-hoc Connection
is returned
using Engine.connect()
on the underlying
Engine
.
Ambiguity in multi-bind or unbound Session
objects can be
resolved through any of the optional keyword arguments. This
ultimately makes usage of the get_bind()
method for resolution.
bind_arguments¶ – dictionary of bind arguments. May include
“mapper”, “bind”, “clause”, other custom arguments that are passed
to Session.get_bind()
.
bind¶ – deprecated; use bind_arguments
mapper¶ – deprecated; use bind_arguments
clause¶ – deprecated; use bind_arguments
close_with_result¶ –
Passed to Engine.connect()
,
indicating the Connection
should be considered
“single use”, automatically closing when the first result set is
closed. This flag only has an effect if this Session
is
configured with autocommit=True
and does not already have a
transaction in progress.
Deprecated since version 1.4: this parameter is deprecated and will be removed in SQLAlchemy 2.0
execution_options¶ –
a dictionary of execution options that will
be passed to Connection.execution_options()
, when the
connection is first procured only. If the connection is already
present within the Session
, a warning is emitted and
the arguments are ignored.
**kw¶ – deprecated; use bind_arguments
sqlalchemy.orm.scoping.scoped_session.
delete(instance)¶Mark an instance as deleted.
Proxied for the Session
class on behalf of the scoped_session
class.
The database delete operation occurs upon flush()
.
sqlalchemy.orm.scoping.scoped_session.
deleted¶The set of all instances marked as ‘deleted’ within this Session
Proxied for the Session
class on behalf of the scoped_session
class.
sqlalchemy.orm.scoping.scoped_session.
dirty¶The set of all persistent instances considered dirty.
Proxied for the Session
class on behalf of the scoped_session
class.
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.
sqlalchemy.orm.scoping.scoped_session.
execute(statement, params=None, execution_options={}, bind_arguments=None, _parent_execute_state=None, _add_event=None, **kw)¶Execute a SQL expression construct.
Proxied for the Session
class on behalf of the scoped_session
class.
Returns a Result
object representing
results of the statement execution.
E.g.:
from sqlalchemy import select
result = session.execute(
select(User).where(User.id == 5)
)
The API contract of Session.execute()
is similar to that
of Connection.execute()
, the 2.0 style version
of Connection
.
Changed in version 1.4: the Session.execute()
method is
now the primary point of ORM statement execution when using
2.0 style ORM usage.
statement¶ – An executable statement (i.e. an Executable
expression
such as select()
).
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.
execution_options¶ – optional dictionary of execution options,
which will be associated with the statement execution. This
dictionary can provide a subset of the options that are accepted
by Connection.execution_options()
, and may also
provide additional options understood only in an ORM context.
bind_arguments¶ – dictionary of additional arguments to determine
the bind. May include “mapper”, “bind”, or other custom arguments.
Contents of this dictionary are passed to the
Session.get_bind()
method.
mapper¶ – deprecated; use the bind_arguments dictionary
bind¶ – deprecated; use the bind_arguments dictionary
**kw¶ – deprecated; use the bind_arguments dictionary
a Result
object.
sqlalchemy.orm.scoping.scoped_session.
expire(instance, attribute_names=None)¶Expire the attributes on an instance.
Proxied for the Session
class on behalf of the scoped_session
class.
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,
use Session.expire_all()
.
The Session
object’s default behavior is to
expire all state whenever the Session.rollback()
or Session.commit()
methods are called, so that new
state can be loaded for the new transaction. For this reason,
calling Session.expire()
only makes sense for the specific
case that a non-ORM SQL statement was emitted in the current
transaction.
See also
Refreshing / Expiring - introductory material
sqlalchemy.orm.scoping.scoped_session.
expire_all()¶Expires all persistent instances within this Session.
Proxied for the Session
class on behalf of the scoped_session
class.
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 the Session.rollback()
or Session.commit()
methods are called, so that new
state can be loaded for the new transaction. For this reason,
calling Session.expire_all()
should not be needed when
autocommit is False
, assuming the transaction is isolated.
See also
Refreshing / Expiring - introductory material
sqlalchemy.orm.scoping.scoped_session.
expunge(instance)¶Remove the instance from this Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
This will free all internal references to the instance. Cascading will be applied according to the expunge cascade rule.
sqlalchemy.orm.scoping.scoped_session.
expunge_all()¶Remove all object instances from this Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
This is equivalent to calling expunge(obj)
on all objects in this
Session
.
sqlalchemy.orm.scoping.scoped_session.
flush(objects=None)¶Flush all the object changes to the database.
Proxied for the Session
class on behalf of the scoped_session
class.
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.
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.
sqlalchemy.orm.scoping.scoped_session.
get(entity, ident, options=None, populate_existing=False, with_for_update=None, identity_token=None)¶Return an instance based on the given primary key identifier,
or None
if not found.
Proxied for the Session
class on behalf of the scoped_session
class.
E.g.:
my_user = session.get(User, 5)
some_object = session.get(VersionedFoo, (5, 10))
some_object = session.get(
VersionedFoo,
{"id": 5, "version_id": 10}
)
New in version 1.4: Added Session.get()
, which is moved
from the now deprecated Query.get()
method.
Session.get()
is special in that it provides direct
access to the identity map of the Session
.
If the given primary key identifier is present
in the local identity map, the object is returned
directly from this collection and no SQL is emitted,
unless the object has been marked fully expired.
If not present,
a SELECT is performed in order to locate the object.
Session.get()
also will perform a check if
the object is present in the identity map and
marked as expired - a SELECT
is emitted to refresh the object as well as to
ensure that the row is still present.
If not, ObjectDeletedError
is raised.
entity¶ – a mapped class or Mapper
indicating the
type of entity to be loaded.
ident¶ –
A scalar, tuple, or dictionary representing the primary key. For a composite (e.g. multiple column) primary key, a tuple or dictionary should be passed.
For a single-column primary key, the scalar calling form is typically the most expedient. If the primary key of a row is the value “5”, the call looks like:
my_object = session.get(SomeClass, 5)
The tuple form contains primary key values typically in
the order in which they correspond to the mapped
Table
object’s primary key columns, or if the
Mapper.primary_key
configuration parameter were
used, in
the order used for that parameter. For example, if the primary key
of a row is represented by the integer
digits “5, 10” the call would look like:
my_object = session.get(SomeClass, (5, 10))
The dictionary form should include as keys the mapped attribute names
corresponding to each element of the primary key. If the mapped class
has the attributes id
, version_id
as the attributes which
store the object’s primary key value, the call would look like:
my_object = session.get(SomeClass, {"id": 5, "version_id": 10})
options¶ – optional sequence of loader options which will be applied to the query, if one is emitted.
populate_existing¶ – causes the method to unconditionally emit a SQL query and refresh the object with the newly loaded data, regardless of whether or not the object is already present.
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.with_for_update()
.
Supersedes the Session.refresh.lockmode
parameter.
The object instance, or None
.
sqlalchemy.orm.scoping.scoped_session.
get_bind(mapper=None, clause=None, bind=None, _sa_skip_events=None, _sa_skip_for_implicit_returning=False)¶Return a “bind” to which this Session
is bound.
Proxied for the Session
class on behalf of the scoped_session
class.
The “bind” is usually an instance of Engine
,
except in the case where the Session
has been
explicitly bound directly to a Connection
.
For a multiply-bound or unbound Session
, the
mapper
or clause
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 a Session.query()
, each
individual INSERT/UPDATE/DELETE operation within a
Session.flush()
, call, etc.
The order of resolution is:
if mapper given and 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 Table
objects
found in the given clause present in Session.binds
.
if Session.binds
is present, return that.
if clause given, attempt to return a bind
linked to the MetaData
ultimately
associated with the clause.
if mapper given, attempt to return a bind
linked to the MetaData
ultimately
associated with the 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 of Session
to provide any kind
of bind resolution scheme. See the example at
Custom Vertical Partitioning.
mapper¶ – Optional mapper()
mapped class or instance of
Mapper
. The bind can be derived from a
Mapper
first by consulting the “binds” map associated with this
Session
, and secondly by consulting the
MetaData
associated with the Table
to which the
Mapper
is mapped for a bind.
clause¶ – A ClauseElement
(i.e.
select()
,
text()
,
etc.). If the mapper
argument is not present or could not
produce a bind, the given expression construct will be searched
for a bound element, typically a Table
associated with
bound MetaData
.
sqlalchemy.orm.scoping.scoped_session.
classmethod identity_key(*args, **kwargs)¶Return an identity key.
Proxied for the Session
class on behalf of the scoped_session
class.
This is an alias of identity_key()
.
sqlalchemy.orm.scoping.scoped_session.
info¶A user-modifiable dictionary.
Proxied for the Session
class on behalf of the scoped_session
class.
The initial value of this dictionary can be populated using the
info
argument to the Session
constructor or
sessionmaker
constructor or factory methods. The dictionary
here is always local to this Session
and can be modified
independently of all other Session
objects.
sqlalchemy.orm.scoping.scoped_session.
is_active¶True if this Session
not in “partial rollback” state.
Proxied for the Session
class on behalf of the scoped_session
class.
Changed in version 1.4: The Session
no longer begins
a new transaction immediately, so this attribute will be False
when the Session
is first instantiated.
“partial rollback” state typically indicates that the flush process
of the Session
has failed, and that the
Session.rollback()
method must be emitted in order to
fully roll back the transaction.
If this Session
is not in a transaction at all, the
Session
will autobegin when it is first used, so in this
case Session.is_active
will return True.
Otherwise, if this Session
is within a transaction,
and that transaction has not been rolled back internally, the
Session.is_active
will also return True.
sqlalchemy.orm.scoping.scoped_session.
is_modified(instance, include_collections=True)¶Return True
if the given instance has locally
modified attributes.
Proxied for the Session
class on behalf of the scoped_session
class.
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
report False
when tested with this method. This is because
the object may have received change events via attribute mutation,
thus placing it in Session.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 to True
.
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 the active_history
argument with column_property()
.
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.
sqlalchemy.orm.scoping.scoped_session.
merge(instance, load=True)¶Copy the state of a given instance into a corresponding instance
within this Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
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 the Session
if not already.
This operation cascades to associated instances if the association is
mapped with cascade="merge"
.
See 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 Session.merge resolves pending conflicts the same as persistent for discussion.
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 a Session
from a second level cache, or to transfer just-loaded objects
into the Session
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 any
Session
. 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 from load=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 the Session
sqlalchemy.orm.scoping.scoped_session.
new¶The set of all instances marked as ‘new’ within this Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
sqlalchemy.orm.scoping.scoped_session.
no_autoflush¶Return a context manager that disables autoflush.
Proxied for the Session
class on behalf of the scoped_session
class.
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.
sqlalchemy.orm.scoping.scoped_session.
classmethod object_session(instance)¶Return the Session
to which an object belongs.
Proxied for the Session
class on behalf of the scoped_session
class.
This is an alias of object_session()
.
sqlalchemy.orm.scoping.scoped_session.
query(*entities, **kwargs)¶Return a new Query
object corresponding to this
Session
.
Proxied for the Session
class on behalf of the scoped_session
class.
sqlalchemy.orm.scoping.scoped_session.
query_property(query_cls=None)¶return a class property which produces a Query
object
against the class and the current Session
when called.
e.g.:
Session = scoped_session(sessionmaker())
class MyClass(object):
query = Session.query_property()
# after mappers are defined
result = MyClass.query.filter(MyClass.name=='foo').all()
Produces instances of the session’s configured query class by
default. To override and use a custom implementation, provide
a query_cls
callable. The callable will be invoked with
the class’s mapper as a positional argument and a session
keyword argument.
There is no limit to the number of query properties placed on a class.
sqlalchemy.orm.scoping.scoped_session.
refresh(instance, attribute_names=None, with_for_update=None)¶Expire and refresh attributes on the given instance.
Proxied for the Session
class on behalf of the scoped_session
class.
The selected attributes will first be expired as they would when using
Session.expire()
; then a SELECT statement will be issued to
the database to refresh column-oriented attributes with the current
value available in the current transaction.
relationship()
oriented attributes will also be immediately
loaded if they were already eagerly loaded on the object, using the
same eager loading strategy that they were loaded with originally.
Unloaded relationship attributes will remain unloaded, as will
relationship attributes that were originally lazy loaded.
New in version 1.4: - the Session.refresh()
method
can also refresh eagerly loaded attributes.
Tip
While the Session.refresh()
method is capable of
refreshing both column and relationship oriented attributes, its
primary focus is on refreshing of local column-oriented attributes
on a single instance. For more open ended “refresh” functionality,
including the ability to refresh the attributes on many objects at
once while having explicit control over relationship loader
strategies, use the
populate existing feature
instead.
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. Refreshing attributes usually only makes sense at the start of a transaction where database rows have not yet been accessed.
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.with_for_update()
.
Supersedes the Session.refresh.lockmode
parameter.
See also
Refreshing / Expiring - introductory material
Populate Existing - allows any ORM query to refresh objects as they would be loaded normally.
sqlalchemy.orm.scoping.scoped_session.
remove()¶Dispose of the current Session
, if present.
This will first call Session.close()
method
on the current Session
, which releases any existing
transactional/connection resources still being held; transactions
specifically are rolled back. The Session
is then
discarded. Upon next usage within the same scope,
the scoped_session
will produce a new
Session
object.
sqlalchemy.orm.scoping.scoped_session.
rollback()¶Rollback the current transaction in progress.
Proxied for the Session
class on behalf of the scoped_session
class.
If no transaction is in progress, this method is a pass-through.
In 1.x-style use, this method rolls back the topmost database transaction if no nested transactions are in effect, or to the current nested transaction if one is in effect.
When
2.0-style use is in effect via the
Session.future
flag, the method always rolls back
the topmost database transaction, discarding any nested
transactions that may be in progress.
sqlalchemy.orm.scoping.scoped_session.
scalar(statement, params=None, execution_options={}, bind_arguments=None, **kw)¶Execute a statement and return a scalar result.
Proxied for the Session
class on behalf of the scoped_session
class.
Usage and parameters are the same as that of
Session.execute()
; the return result is a scalar Python
value.
sqlalchemy.orm.scoping.scoped_session.
session_factory = None¶The session_factory provided to __init__ is stored in this
attribute and may be accessed at a later time. This can be useful when
a new non-scoped Session
or Connection
to the
database is needed.
A Registry that can store one or multiple instances of a single class on the basis of a “scope” function.
The object implements __call__
as the “getter”, so by
calling myregistry()
the contained object is returned
for the current scope.
sqlalchemy.util.ScopedRegistry.
__init__(createfunc, scopefunc)¶Construct a new ScopedRegistry
.
sqlalchemy.util.ScopedRegistry.
clear()¶Clear the current scope, if any.
sqlalchemy.util.ScopedRegistry.
has()¶Return True if an object is present in the current scope.
sqlalchemy.util.ScopedRegistry.
set(obj)¶Set the value for the current scope.
A ScopedRegistry
that uses a threading.local()
variable for storage.
Class signature
class sqlalchemy.util.ThreadLocalRegistry
(sqlalchemy.util.ScopedRegistry
)
flambé! the dragon and The Alchemist image designs created and generously donated by Rotem Yaari.
Created using Sphinx 4.2.0.