| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
via :paramref:`.create_engine.isolation_level` and
:paramref:`.Connection.execution_options.isolation_level`
parameters. fixes #3534
|
| | |
|
| |
|
|
| |
back by using an attrgetter for the default case
|
| |
|
|
| |
have it; keep it simple
|
| |
|
|
|
|
|
|
|
| |
This supports the use case of an application that uses the same set of
:class:`.Table` objects in many schemas, such as schema-per-user.
A new execution option
:paramref:`.Connection.execution_options.schema_translate_map` is
added. fixes #2685
- latest tox doesn't like the {posargs} in the profile rerunner
|
| |
|
|
|
|
|
|
| |
no longer called for an UPDATE or DELETE statement emitted via plain
text or via the :func:`.text` construct, affecting those drivers
that erase cursor.rowcount once the cursor is closed such as SQL
Server ODBC and Firebird drivers.
fixes #3622
|
| |
|
|
| |
(cherry picked from commit 3ef00e816da042d4932be53b86f76db17c800842)
|
| | |
|
| | |
|
| |
|
|
| |
Called after the :meth:`.Engine.dispose` method is called.
|
| |
|
|
|
|
|
|
|
|
|
| |
pep-249 exception names linked to exception classes of an entirely
different name, preventing SQLAlchemy's own exception wrapping from
wrapping the error appropriately.
The SQLAlchemy dialect in use needs to implement a new
accessor :attr:`.DefaultDialect.dbapi_exception_translation_map`
to support this feature; this is implemented now for the py-postgresql
dialect.
fixes #3421
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functionality. Added a new "soft invalidate" feature to the
connection pool at the level of the checked out connection wrapper
as well as the :class:`._ConnectionRecord`. This works similarly
to a modern pool invalidation in that connections aren't actively
closed, but are recycled only on next checkout; this is essentially
a per-connection version of that feature. A new event
:class:`.PoolEvents.soft_invalidate` is added to complement it.
fixes #3379
- Added new flag
:attr:`.ExceptionContext.invalidate_pool_on_disconnect`.
Allows an error handler within :meth:`.ConnectionEvents.handle_error`
to maintain a "disconnect" condition, but to handle calling invalidate
on individual connections in a specific manner within the event.
- Added new event :class:`.DialectEvents.do_connect`, which allows
interception / replacement of when the :meth:`.Dialect.connect`
hook is called to create a DBAPI connection. Also added
dialect plugin hooks :meth:`.Dialect.get_dialect_cls` and
:meth:`.Dialect.engine_created` which allow external plugins to
add events to existing dialects using entry points.
fixes #3355
|
| |
|
|
|
|
|
|
|
|
|
| |
That is, after exhausing all rows using the fetch methods, the
DBAPI cursor is released as before and the object may be safely
discarded, but the fetch methods may continue to be called for which
they will return an end-of-result object (None for fetchone, empty list
for fetchmany and fetchall). Only if :meth:`.ResultProxy.close`
is called explicitly will these methods raise the "result is closed"
error.
fixes #3330 fixes #3329
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
persistence.py could theoretically hit the limit of the cache
(100 items by default) and at some points fail to have a key that
we check for, due to the cleanup. This has never been observed
so its likely that so far, the total number of INSERT, UPDATE and
DELETE statement structures in real apps has not exceeded 100
on a per-mapper basis; this could happen for apps that run a
very wide variety of attribute modified combinations into the unit
of work, *and* which have very high concurrency going on.
This change will be a lot more significant when we open up
use of LRUCache + compiled cache with the baked query extension.
|
| |
|
|
|
|
|
|
|
| |
:meth:`.Connection.invalidate` method, or an invalidation due
to a database disconnect, would fail if the
``isolation_level`` parameter had been used with
:meth:`.Connection.execution_options`; the "finalizer" that resets
the isolation level would be called on the no longer opened connection.
fixes #3302
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with :meth:`.Connection.execution_options` when a :class:`.Transaction`
is in play; DBAPIs and/or SQLAlchemy dialects such as psycopg2,
MySQLdb may implicitly rollback or commit the transaction, or
not change the setting til next transaction, so this is never safe.
- Added new parameter :paramref:`.Session.connection.execution_options`
which may be used to set up execution options on a :class:`.Connection`
when it is first checked out, before the transaction has begun.
This is used to set up options such as isolation level on the
connection before the transaction starts.
- added new documentation section
detailing best practices for setting transaction isolation with
sessions.
fixes #3296
|
| |
|
|
|
|
| |
for a for-loop through an empty tuple. we add one more local flag
to handle the logic without repetition of dialect.do_execute()
calls.
|
| |
|
|
|
|
|
|
|
|
| |
logic to some degree in DefaultExecutionContext. In particular
we are removing post_insert() which doesn't appear to be used
based on a survey of prominent third party dialects. Callcounts
aren't added to existing execute profiling tests and inserts might be
a little better.
- simplify the execution_options join in DEC. Callcounts don't
appear affected.
|
| |
|
|
|
|
|
|
|
| |
levels; :meth:`.Connection.get_isolation_level`,
:attr:`.Connection.default_isolation_level`.
- enhance documentation inter-linkage between new accessors,
existing isolation_level parameters, as well as in
the dialect-level methods which should be fully covered
by Engine/Connection level APIs now.
|
| | |
|
| | |
|
| |
|
|
|
| |
differently for the case where it is called in an already-invalidated state;
don't call upon self.connection
|
| |
|
|
|
|
|
| |
_handle_dbapi_exception_noconnection() to only invoke in the case
of raw_connection() in the constructor of Connection. in all other
cases the Connection proceeds with _handle_dbapi_exception() including
revalidate.
|
| |
|
|
|
|
|
|
|
|
| |
to it, so that we say we will do the wrapping just once right here
in _execute_context() / _execute_default(). An adjustment is made
to _handle_dbapi_error() to not assume self.__connection in case
we are already in an invalidated state
further adjustment to
0639c199a547343d62134d2f233225fd2862ec45, 41e7253dee168b8c26c49, #3266
|
| |
|
|
|
| |
_handle_dbapi_error(); these are now handled already and the reentrant
call is not needed / breaks things. Adjustment to 41e7253dee168b8c26c49 /
|
| |
|
|
|
|
|
|
|
| |
take effect in all engine connection use cases, including
when user-custom connect routines are used via the
:paramref:`.create_engine.creator` parameter, as well as when
the :class:`.Connection` encounters a connection error on
revalidation.
fixes #3266
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
when you call :meth:`.Connection.connect`, would not share transaction
status with the parent. The architecture of branching has been tweaked
a bit so that the branched connection defers to the parent for
all transactional status and operations.
fixes #3190
|
| |/
|
|
|
|
|
|
| |
when you call :meth:`.Connection.connect`, would not share invalidation
status with the parent. The architecture of branching has been tweaked
a bit so that the branched connection defers to the parent for
all invalidation status and operations.
fixes #3215
|
| |
|
|
|
|
|
|
| |
view. So copy collections.OrderedDict and use MutableMapping to set up
keys, items, values on our own OrderedDict.
Conflicts:
lib/sqlalchemy/engine/base.py
|
| | |
|
| |
|
|
|
|
|
|
|
| |
for an INSERT or UPDATE are now sorted when they contribute towards
the "compiled cache" cache key. These keys were previously not
deterministically ordered, meaning the same statement could be
cached multiple times on equivalent keys, costing both in terms of
memory as well as performance.
fixes #3165
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
events from firing for those statements which it uses internally
to detect if a table exists or not. This is achieved using an
execution option ``skip_user_error_events`` that disables the handle
error event for the scope of that execution. In this way, user code
that rewrites exceptions doesn't need to worry about the MySQL
dialect or other dialects that occasionally need to catch
SQLAlchemy specific exceptions.
|
| | |
|
| |
|
|
| |
to get all flake8 passing
|
| |
|
|
|
|
|
|
|
|
|
| |
in all cases unconditionally, the number of use cases that go beyond what
dbapi_error() is expecting has gone too far for an 0.9 release.
Additionally, the number of things we'd like to track is really a lot
more than the five arguments here, and ExecutionContext is really not
suitable as totally public API for this. So restore dbapi_error
to its old version, deprecate, and build out handle_error instead.
This is a lot more extensible and doesn't get in the way of anything
compatibility-wise.
|
| |
|
|
|
|
|
| |
:attr:`.ExecutionContext.is_disconnect` which are meaningful within
the :meth:`.ConnectionEvents.dbapi_error` handler to see both the
original DBAPI error as well as whether or not it represents
a disconnect.
|
| |
|
|
|
|
|
| |
have been enhanced such that the function handler is now capable
of raising or returning a new exception object, which will replace
the exception normally being thrown by SQLAlchemy.
fixes #3076
|
| |
|
|
|
|
|
|
|
|
|
| |
- Fixed bug which would occur if a DBAPI exception
occurs when the engine first connects and does its initial checks,
and the exception is not a disconnect exception, yet the cursor
raises an error when we try to close it. In this case the real
exception would be quashed as we tried to log the cursor close
exception via the connection pool and failed, as we were trying
to access the pool's logger in a way that is inappropriate
in this very specific scenario. fixes #3063
|
| |\
| |
| | |
Documentation fix-up: "its" vs. "it's"
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Removed ungrammatical apostrophes from documentation, replacing
"it's" with "its" where appropriate (but in a few cases with "it is"
when that read better).
While doing that, I also fixed a couple of minor typos etc.
as I noticed them.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a connection invalidation could occur within an already critical section
like a connection.close(); ultimately, these conditions are caused
by the change in :ticket:`2907`, in that the "reset on return" feature
calls out to the Connection/Transaction in order to handle it, where
"disconnect detection" might be caught. However, it's possible that
the more recent change in :ticket:`2985` made it more likely for this
to be seen as the "connection invalidate" operation is much quicker,
as the issue is more reproducible on 0.9.4 than 0.9.3.
Checks are now added within any section that
an invalidate might occur to halt further disallowed operations
on the invalidated connection. This includes two fixes both at the
engine level and at the pool level. While the issue was observed
with highly concurrent gevent cases, it could in theory occur in
any kind of scenario where a disconnect occurs within the connection
close operation.
fixes #3043
ref #2985
ref #2907
- add some defensive checks during an invalidate situation:
1. _ConnectionRecord.invalidate might be called twice within finalize_fairy
if the _reset() raises an invalidate condition, invalidates, raises and then
goes to invalidate the CR. so check for this.
2. similarly within Conneciton, anytime we do handle_dbapi_error(), we might become invalidated.
so a following finally must check self.__invalid before dealing with the connection
any futher.
|
| |
|
|
| |
Found using: https://github.com/intgr/topy
|
| |
|
|
|
|
|
|
|
|
|
| |
1. make sure pool._invalidate() sets the timestamp up before
invalidating the target connection. we can otherwise show how the
conn.invalidate() + pool._invalidate() can lead to an extra connection
being made.
2. to help with that, soften up the check on connection.invalidate()
when connection is already closed. a warning is fine here
3. add a mutex to test_max_overflow() when we connect, because the way
we're using mock depends on an iterator, that needs to be synchronized
|
| |
|
|
|
|
|
| |
implementation allows an event handler to redefine the specific mechanics
by which an arbitrary dialect invokes execute() or executemany() on a
DBAPI cursor. The new events, at this point semi-public and experimental,
are in support of some upcoming transaction-related extensions.
|