summaryrefslogtreecommitdiff
path: root/lib/sqlalchemy/engine/base.py
Commit message (Collapse)AuthorAgeFilesLines
* Remove RootTransaction<->RootTransaction reference cycleJakub Stasiak2015-07-181-1/+5
| | | | (cherry picked from commit 3ef00e816da042d4932be53b86f76db17c800842)
* - more edits, references #3461Mike Bayer2015-06-191-2/+4
|
* - add explciit section on engine disposal, fixes #3461Mike Bayer2015-06-191-14/+10
|
* - Added new engine event :meth:`.ConnectionEvents.engine_disposed`.Mike Bayer2015-06-061-0/+1
| | | | Called after the :meth:`.Engine.dispose` method is called.
* - Added support for the case of the misbehaving DBAPI that hasMike Bayer2015-05-151-2/+4
| | | | | | | | | | | 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
* - New features added to support engine/pool plugins with advancedMike Bayer2015-04-301-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* - The "auto close" for :class:`.ResultProxy` is now a "soft" close.Mike Bayer2015-03-171-2/+2
| | | | | | | | | | | 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
* - copyright 2015Mike Bayer2015-03-101-1/+1
|
* - fix a potential race condition where the per-mapper LRUCache used byMike Bayer2015-03-091-3/+2
| | | | | | | | | | | | | 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.
* - Fixed bug in :class:`.Connection` and pool where theMike Bayer2015-02-041-0/+7
| | | | | | | | | :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
* - A warning is emitted if the ``isolation_level`` parameter is usedMike Bayer2015-02-041-0/+14
| | | | | | | | | | | | | | | | 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
* - remove the clever approach w/ dialect events, and remove the needMike Bayer2015-01-251-17/+20
| | | | | | 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.
* - remove context-specific post-crud logic from Connection and inline post-crudMike Bayer2015-01-251-24/+5
| | | | | | | | | | 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.
* - Added new user-space accessors for viewing transaction isolationMike Bayer2015-01-201-11/+107
| | | | | | | | | 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.
* correctionsMike Bayer2014-12-271-1/+1
|
* - keep working on fixing #3266, more cases, more testsMike Bayer2014-12-101-4/+5
|
* - identify another spot where _handle_dbapi_error() needs to do somethingMike Bayer2014-12-081-3/+4
| | | | | differently for the case where it is called in an already-invalidated state; don't call upon self.connection
* - simplify the "noconnection" error handling, settingMike Bayer2014-12-081-17/+19
| | | | | | | _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.
* - adjust _revalidate_connection() again such that we pass a _wrap=FalseMike Bayer2014-12-051-20/+26
| | | | | | | | | | 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
* - move inner calls to _revalidate_connection() outside of existingMike Bayer2014-12-051-8/+9
| | | | | _handle_dbapi_error(); these are now handled already and the reentrant call is not needed / breaks things. Adjustment to 41e7253dee168b8c26c49 /
* - The engine-level error handling and wrapping routines will nowMike Bayer2014-12-051-6/+68
| | | | | | | | | 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
* Merge remote-tracking branch 'origin/pr/140' into pr140Mike Bayer2014-10-111-2/+0
|\
| * cleanup exception handling - use new exception hierarchy (since python 2.5)pr/140ndparker2014-10-021-4/+0
| |
| * improve exception vs. exit handlingndparker2014-09-231-0/+2
| |
* | - repair autorollback for branchesMike Bayer2014-09-261-2/+2
| |
* | - Fixed bug where a "branched" connection, that is the kind you getMike Bayer2014-09-261-37/+87
| | | | | | | | | | | | | | | | 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
* | - Fixed bug where a "branched" connection, that is the kind you getMike Bayer2014-09-261-11/+32
|/ | | | | | | | 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
* - TIL that dict.keys() in py3K is not an iterator, it is an iterableMike Bayer2014-08-151-2/+2
| | | | | | | | view. So copy collections.OrderedDict and use MutableMapping to set up keys, items, values on our own OrderedDict. Conflicts: lib/sqlalchemy/engine/base.py
* - other test fixesMike Bayer2014-08-151-1/+1
|
* - The string keys that are used to determine the columns impactedMike Bayer2014-08-141-1/+1
| | | | | | | | | 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
* - more pg8000 tests passingMike Bayer2014-07-251-1/+0
|
* - The MySQL dialect will now disable :meth:`.ConnectionEvents.handle_error`Mike Bayer2014-07-251-1/+3
| | | | | | | | | | 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.
* PEP8 style fixesBrian Jarrett2014-07-131-111/+117
|
* - break up the <authors> copyright comment as part of a passMike Bayer2014-07-091-1/+2
| | | | to get all flake8 passing
* - rework the entire approach to #3076. As we need to catch all exceptionsMike Bayer2014-07-041-29/+62
| | | | | | | | | | | 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.
* - Added new attributes :attr:`.ExecutionContext.exception` andMike Bayer2014-07-031-1/+7
| | | | | | | :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.
* - The mechanics of the :meth:`.ConnectionEvents.dbapi_error` handlerMike Bayer2014-07-031-7/+23
| | | | | | | 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
* - vastly improve the "safe close cursor" tests in test_reconnectMike Bayer2014-05-301-2/+3
| | | | | | | | | | | - 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
* Merge pull request #91 from smurfix/de_apostroph_ifymike bayer2014-05-111-1/+1
|\ | | | | Documentation fix-up: "its" vs. "it's"
| * Documentation fix-up: "its" vs. "it's"pr/91Matthias Urlichs2014-05-111-1/+1
| | | | | | | | | | | | | | | | | | 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.
* | - Fixed some "double invalidate" situations were detected whereMike Bayer2014-05-101-3/+10
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix many typos throughout the codebasepr/85Alex Gaynor2014-04-261-1/+1
| | | | Found using: https://github.com/intgr/topy
* - work on fixing some race-condition failures:Mike Bayer2014-03-261-1/+1
| | | | | | | | | | | 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
* - Added some new event mechanics for dialect-level events; the initialMike Bayer2014-03-241-19/+41
| | | | | | | 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.
* - An event listener can now be associated with a :class:`.Engine`,Mike Bayer2014-03-221-28/+31
| | | | | | | | | | 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
* - restore the old behavior of the connection pool replacing itself justMike Bayer2014-03-221-0/+1
| | | | | | | | 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.
* - A major improvement made to the mechanics by which the :class:`.Engine`Mike Bayer2014-03-221-4/+2
| | | | | | | | | | | | 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
* - The :meth:`.ConnectionEvents.after_cursor_execute` event is nowMike Bayer2014-03-191-4/+11
| | | | | | | | | | | | 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.
* - Added :paramref:`.MetaData.reflect.**dialect_kwargs`Mike Bayer2014-02-021-7/+16
| | | | | | | | | | | | | | | | | | 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]
* - continue with [ticket:2907] and further clean up how we set upMike Bayer2014-01-131-17/+41
| | | | | | | | | | | | | | _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).
View Lorry Controller Status