| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The "wrapping" employed by the mssql and oracle dialects using the
"iswrapper" argument was not being used intelligently by the compiler,
and the result map was being written incorrectly, using
*more* columns in the result map than were actually returned by
the statement, due to "row number" columns that are inside the
subquery. The compiler now writes out result map on the
"top level" select in all cases
fully, and for the mssql/oracle wrapping case extracts out
the "proxied" columns in a second step, which only includes
those columns that are proxied outwards to the top level.
This change might have implications for 3rd party dialects that
might be imitating oracle's approach. They can safely continue
to use the "iswrapper" kw which is now ignored, but they may
need to also add the _select_wraps argument as well.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
such that they are matched to the received result set positionally,
rather than by name. Originally, this was seen as a way to handle
cases where we had columns returned with difficult-to-predict names,
though in modern use that issue has been overcome by anonymous
labeling. In this version, the approach basically reduces function
call count per-result by a few dozen calls, or more for larger
sets of result columns. The approach still degrades into a modern
version of the old approach if textual elements modify the result
map, or if any discrepancy in size exists between
the compiled set of columns versus what was received, so there's no
issue for partially or fully textual compilation scenarios where these
lists might not line up. fixes #918
- callcounts still need to be adjusted down for this so zoomark
tests won't pass at the moment
|
|
|
|
|
|
|
|
|
| |
: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.
|
|
|
|
|
|
|
|
|
|
|
|
| |
repaired to work more usefully with tables that have Python-
side default values and/or functions, as well as server-side
defaults. The feature will now work with a dialect that uses
"positional" parameters; a Python callable will also be
invoked individually for each row just as is the case with an
"executemany" style invocation; a server- side default column
will no longer implicitly receive the value explicitly
specified for the first row, instead refusing to invoke
without an explicit value. fixes #3288
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sort_tables_and_constraints function.
- The DDL generation system of :meth:`.MetaData.create_all`
and :meth:`.Metadata.drop_all` has been enhanced to in most
cases automatically handle the case of mutually dependent
foreign key constraints; the need for the
:paramref:`.ForeignKeyConstraint.use_alter` flag is greatly
reduced. The system also works for constraints which aren't given
a name up front; only in the case of DROP is a name required for
at least one of the constraints involved in the cycle.
fixes #3282
|
| |
|
| |
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Patch courtesy Gabor Gombas.
fixes #3127
|
|
|
|
|
|
|
| |
for psycopg2 and others, encourage users to take advantage of positional
styles by documenting "paramstyle". A section is added to psycopg2
specifically as this is a pretty common spot for named parameters
that may be unusually named. fixes #3246.
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
that union() can be called, in the case of a dialect that uses
execution options inside of initialize() (e.g. oursql)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
:paramref:`.create_engine.execution_options` or
:meth:`.Engine.update_execution_options` are not passed to the
special :class:`.Connection` used to initialize the dialect
within the "first connect" event; dialects will usually
perform their own queries in this phase, and none of the
current available options should be applied here. In
particular, the "autocommit" option was causing an attempt to
autocommit within this initial connect which would fail with
an AttributeError due to the non-standard state of the
:class:`.Connection`.
fixes #3200
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- add a test for PG reflection of unique index without any unique
constraint
- for PG, don't include 'duplicates_constraint' in the entry
if the index does not actually mirror a constraint
- use a distinct method for unique constraint reflection within table
- catch unique constraint not implemented condition; this may
be within some dialects and also is expected to be supported by
Alembic tests
- migration + changelogs for #3184
- add individual doc notes as well to MySQL, Postgreql
fixes #3184
|
|\ \
| | |
| | |
| | | |
https://bitbucket.org/jerdfelt/sqlalchemy into pr30
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Calls to reflect a table did not create any UniqueConstraint objects.
The reflection core made no calls to get_unique_constraints and as
a result, the sqlite dialect would never reflect any unique constraints.
MySQL transparently converts unique constraints into unique indexes, but
SQLAlchemy would reflect those as an Index object and as a
UniqueConstraint. The reflection core will now deduplicate the unique
constraints.
PostgreSQL would reflect unique constraints as an Index object and as
a UniqueConstraint object. The reflection core will now deduplicate
the unique indexes.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
:meth:`.Inspector.get_temp_view_names`; currently, only the
SQLite dialect supports these methods. The return of temporary
table and view names has been **removed** from SQLite's version
of :meth:`.Inspector.get_table_names` and
:meth:`.Inspector.get_view_names`; other database backends cannot
support this information (such as MySQL), and the scope of operation
is different in that the tables can be local to a session and
typically aren't supported in remote schemas.
fixes #3204
|
| |
|
|
|
|
|
|
|
| |
reports a column that isn't found to be present in the table,
a warning is emitted and the column is skipped. This can occur
for some special system column situations as has been observed
with Oracle. fixes #3180
|
|
|
|
|
|
|
|
|
|
|
| |
any speed improvements :(. code is in a much better place to be run into
C, however
- The ``proc()`` callable passed to the ``create_row_processor()``
method of custom :class:`.Bundle` classes now accepts only a single
"row" argument.
- Deprecated event hooks removed: ``populate_instance``,
``create_instance``, ``translate_row``, ``append_result``
- the getter() idea is somewhat restored; see ref #3175
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
rules, better message formatting
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|