| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
- 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.
|
| |
|
|
|
|
|
|
|
|
| |
after one or more :class:`.Connection` objects have been created
(such as by an orm :class:`.Session` or via explicit connect)
and the listener will pick up events from those connections.
Previously, performance concerns pushed the event transfer from
:class:`.Engine` to :class:`.Connection` at init-time only, but
we've inlined a bunch of conditional checks to make this possible
without any additional function calls. fixes #2978
|
| |
|
|
|
|
|
|
| |
within userland engine.dispose(); as some SQLA tests already failed when the replace step
was removed, due to those conns still being referenced, it's likely this will
create surprises for all those users that incorrectly use dispose()
and it's not really worth dealing with. This doesn't affect the change
we made for ref: #2985.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
recycles the connection pool when a "disconnect" condition is detected;
instead of discarding the pool and explicitly closing out connections,
the pool is retained and a "generational" timestamp is updated to
reflect the current time, thereby causing all existing connections
to be recycled when they are next checked out. This greatly simplifies
the recycle process, removes the need for "waking up" connect attempts
waiting on the old pool and eliminates the race condition that many
immediately-discarded "pool" objects could be created during the
recycle operation. fixes #2985
|
| |
|
|
|
|
|
|
|
|
|
|
| |
emitted for the "_cursor_execute()" method of :class:`.Connection`;
this is the "quick" executor that is used for things like
when a sequence is executed ahead of an INSERT statement, as well as
for dialect startup checks like unicode returns, charset, etc.
the :meth:`.ConnectionEvents.before_cursor_execute` event was already
invoked here. The "executemany" flag is now always set to False
here, as this event always corresponds to a single execution.
Previously the flag could be True if we were acting on behalf of
an executemany INSERT statement.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to support dialect-level reflection options for all :class:`.Table`
objects reflected.
- Added a new dialect-level argument ``postgresql_ignore_search_path``;
this argument is accepted by both the :class:`.Table` constructor
as well as by the :meth:`.MetaData.reflect` method. When in use
against Postgresql, a foreign-key referenced table which specifies
a remote schema name will retain that schema name even if the name
is present in the ``search_path``; the default behavior since 0.7.3
has been that schemas present in ``search_path`` would not be copied
to reflected :class:`.ForeignKey` objects. The documentation has been
updated to describe in detail the behavior of the ``pg_get_constraintdef()``
function and how the ``postgresql_ignore_search_path`` feature essentially
determines if we will honor the schema qualification reported by
this function or not. [ticket:2922]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
_reset_agent, so that it's local to the various begin_impl(),
rollback_impl(), etc. this allows setting/resetting of the flag
to be symmetric.
- don't set _reset_agent if it's not None, don't unset it if it isn't
our own transaction.
- make sure we clean it out in close().
- basically, we're dealing here with pools using "threadlocal" that have a
counter, other various mismatches that the tests bring up
- test for recover() now has to invalidate() the previous connection,
because closing it actually rolls it back (e.g. this test was relying
on the broken behavior).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
:class:`.RootTransaction` or :class:`.TwoPhaseTransaction`
with its immediate :class:`._ConnectionFairy` as a "reset handler"
for the span of that transaction, which takes over the task
of calling commit() or rollback() for the "reset on return" behavior
of :class:`.Pool` if the transaction was not otherwise completed.
This resolves the issue that a picky transaction
like that of MySQL two-phase will be
properly closed out when the connection is closed without an
explicit rollback or commit (e.g. no longer raises "XAER_RMFAIL"
in this case - note this only shows up in logging as the exception
is not propagated within pool reset).
This issue would arise e.g. when using an orm
:class:`.Session` with ``twophase`` set, and then
:meth:`.Session.close` is called without an explicit rollback or
commit. The change also has the effect that you will now see
an explicit "ROLLBACK" in the logs when using a :class:`.Session`
object in non-autocommit mode regardless of how that session was
discarded. Thanks to Jeff Dairiki and Laurence Rowe for isolating
the issue here. [ticket:2907]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
events including auto-invalidation, which is useful both for tests here as well as
detecting failure conditions within the "reset" or "close" cases.
- rename the argument for PoolEvents.reset() to dbapi_connection and connection_record
to be consistent with everything else.
- add new documentation sections on invalidation, including auto-invalidation
and the invalidation process within the pool.
- add _ConnectionFairy and _ConnectionRecord to the pool documentation. Establish
docs for common _ConnectionFairy/_ConnectionRecord methods and accessors and
have PoolEvents docs refer to _ConnectionRecord,
since it is passed to all events. Rename a few _ConnectionFairy methods that are actually
private to pool such as _checkout(), _checkin() and _checkout_existing(); there should not
be any external code calling these
|
| | |
|
| |
|
|
|
|
|
| |
when a pre-DBAPI :class:`.StatementError` were raised within
:meth:`.Connection.execute`, causing encoding errors for
non-ASCII statements. The stringification now remains within
Python unicode thus avoiding encoding errors. [ticket:2871]
|
| |\
| |
| | |
Hide password in URL and Engine __repr__
|
| | |
| |
| |
| | |
Fixes #2821
|
| |/
|
|
| |
pattern
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of relying upon various ``quote=True`` flags being passed around,
these flags are converted into rich string objects with quoting information
included at the point at which they are passed to common schema constructs
like :class:`.Table`, :class:`.Column`, etc. This solves the issue
of various methods that don't correctly honor the "quote" flag such
as :meth:`.Engine.has_table` and related methods. The :class:`.quoted_name`
object is a string subclass that can also be used explicitly if needed;
the object will hold onto the quoting preferences passed and will
also bypass the "name normalization" performed by dialects that
standardize on uppercase symbols, such as Oracle, Firebird and DB2.
The upshot is that the "uppercase" backends can now work with force-quoted
names, such as lowercase-quoted names and new reserved words.
[ticket:2812]
|
| |
|
|
|
| |
- modernize test for that
- use py3k compatible next() in test_returning/test_versioning
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to rely upon server generated version identifiers, using triggers
or other database-provided versioning features, by passing the value
``False``. The ORM will use RETURNING when available to immediately
load the new version identifier, else it will emit a second SELECT.
[ticket:2793]
- The ``eager_defaults`` flag of :class:`.Mapper` will now allow the
newly generated default values to be fetched using an inline
RETURNING clause, rather than a second SELECT statement, for backends
that support RETURNING.
- Added a new variant to :meth:`.ValuesBase.returning` called
:meth:`.ValuesBase.return_defaults`; this allows arbitrary columns
to be added to the RETURNING clause of the statement without interfering
with the compilers usual "implicit returning" feature, which is used to
efficiently fetch newly generated primary key values. For supporting
backends, a dictionary of all fetched values is present at
:attr:`.ResultProxy.returned_defaults`.
- add a glossary entry for RETURNING
- add documentation for version id generation, [ticket:867]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the import structure of many core modules.
``sqlalchemy.schema`` and ``sqlalchemy.types``
remain in the top-level package, but are now just lists of names
that pull from within ``sqlalchemy.sql``. Their implementations
are now broken out among ``sqlalchemy.sql.type_api``, ``sqlalchemy.sql.sqltypes``,
``sqlalchemy.sql.schema`` and ``sqlalchemy.sql.ddl``, the last of which was
moved from ``sqlalchemy.engine``. ``sqlalchemy.sql.expression`` is also
a namespace now which pulls implementations mostly from ``sqlalchemy.sql.elements``,
``sqlalchemy.sql.selectable``, and ``sqlalchemy.sql.dml``.
Most of the "factory" functions
used to create SQL expression objects have been moved to classmethods
or constructors, which are exposed in ``sqlalchemy.sql.expression``
using a programmatic system. Care has been taken such that all the
original import namespaces remain intact and there should be no impact
on any existing applications. The rationale here was to break out these
very large modules into smaller ones, provide more manageable lists
of function names, to greatly reduce "import cycles" and clarify the
up-front importing of names, and to remove the need for redundant
functions and documentation throughout the expression package.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ConnectionRecord/ConnectionFairy is clear;
make sure that the DBAPI connection passed to the reset-on-return events/dialect hooks
is also a "fairy", so that dictionaries like "info" are available. [ticket:2770]
- rework the execution_options system so that the dialect is given the job of making
any immediate adjustments based on a set event. move the "isolation level" logic to use
this new system. Also work things out so that even engine-level execution options
can be used for things like isolation level; the dialect attaches a connect-event
handler in this case to handle the task.
- to support this new system as well as further extensibiltiy of execution options
add events engine_connect(), set_connection_execution_options(), set_engine_execution_options()
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
| |
|
|
|
|
|
|
|
| |
a rollback() before re-raising, so that the stack
trace is preserved from sys.exc_info() before entering
the rollback. This so that the traceback is preserved
when using coroutine frameworks which may have switched
contexts before the rollback function returns.
[ticket:2703]
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
handling. If a non-disconnect error occurs,
but leads to a delayed disconnect error within error
handling (happens with MySQL), the disconnect condition
is detected. The Connection can now also be closed
when in an invalid state, meaning it will raise "closed"
on next usage, and additionally the "close with result"
feature will work even if the autorollback in an error
handling routine fails and regardless of whether the
condition is a disconnect or not.
[ticket:2695]
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
whereas the other do_rollback_twophase(), savepoint etc. work with
:class:`.Connection`. the context on these are different as twophase/savepoint
are available at the :class:`.Connection` level, whereas commit/rollback are needed
at a lower level as well. Rename the argument to "dbapi_connection" when the conneciton
is in fact the DBAPI interface.
- start thinking about being able to track "autocommit" vs. "commit", but not sure
we have a need for this yet.
- have Pool call out to a Dialect for all rollback/commit/close operations now. Pool
no longer calls DBAPI methods directly. May use this for a workaround for [ticket:2611]
- add a new Pool event reset() to allow the pool's reset of the connection to be intercepted.
- remove methods in Informix dialect which appear to be hardcoding some isolation
settings on new Transaction only; the isolation API should be implemented for Informix.
also removed "flag" for transaction commit/rollback being not available; this should
be based on server/DBAPI version and we will need someone with test access in order
to help determine how this should work
|
| |\
| |
| |
| | |
of DVCS
|
| | | |
|
| |/ |
|
| |\ |
|
| | | |
|
| |/
|
|
|
|
|
| |
methods now return a "branched" version so that the :meth:`.Connection.close`
method can be called on the returned connection without affecting the
original. Allows symmetry when using :class:`.Engine` and
:class:`.Connection` objects as context managers.
|
| |
|
|
| |
- it appears we can get rid of all those "XYZ_toplevel" names and use :doc:.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
to :class:`.Engine`. This method works similarly to
:class:`.Connection.execution_options` in that it creates
a copy of the parent object which will refer to the new
set of options. The method can be used to build
sharding schemes where each engine shares the same
underlying pool of connections. The method
has been tested against the horizontal shard
recipe in the ORM as well.
|
| |
|
|
|
|
|
| |
would double up columns if the same constraint/table
existed in multiple schemas.
- force returns_rows to False for inserts where we know rows shouldnt be returned;
allows post_exec() to use the cursor without issue
|
| | |
|
| |
|
|
|
|
| |
- enhancements to test suite including ability to set up a testing engine
for a whole test class, fixes to how noseplugin sets up/tears
down per-class context
|
