| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
| |
the string label placed in the order_by() or group_by() of a statement
would place higher priority on the name as found
inside the FROM clause instead of a more locally available name
inside the columns clause.
fixes #3335
|
|
|
|
|
|
| |
out.
- add __backend__ to the dialect suite so that it runs on CI.
- will be 1.0.0b3
|
|\
| |
| |
| |
| | |
Conflicts:
lib/sqlalchemy/dialects/mysql/mysqldb.py
|
| | |
|
| |
| |
| |
| | |
these files are present.
|
| | |
|
|\ \
| | |
| | |
| | | |
https://bitbucket.org/graingert/sqlalchemy into pr49
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
objects, such that they were prevented from being called outside
of the declarative process; this is related to the enhancements
of #3150 which allow ``@declared_attr`` to return a value that is
cached based on the current class as it's being configured.
The exception raise has been removed, and the behavior changed
so that outside of the declarative process, the function decorated by
``@declared_attr`` is called every time just like a regular
``@property``, without using any caching, as none is available
at this stage.
fixes #3331
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | | |
|
| | |
| | |
| | |
| | | |
since they've apparently added something for it
|
| | | |
|
| |/
|/| |
|
| | |
|
| |
| |
| |
| | |
to be using getattr
|
| |
| |
| |
| |
| | |
unfortunately Sphinx refuses to work correctly for the columns
attribute so we just add a lame message to contains_column().
|
| |
| |
| |
| |
| |
| |
| |
| | |
simple but unusual system allows for a dramatic savings in Python
overhead for the construction and processing of orm :class:`.Query`
objects, from query construction up through rendering of a string
SQL statement.
fixes #3054
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
:attr:`.Query.column_descriptions`. This refers to the primary ORM
mapped class or aliased class that is referred to by the expression.
Compared to the existing entry for ``"type"``, it will always be
a mapped entity, even if extracted from a column expression, or
None if the given expression is a pure core expression.
references #3320
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DROP TYPE instruction when a plain ``table.drop()`` is called,
assuming the object is not associated directly with a
:class:`.MetaData` object. In order to accomodate the use case of
an enumerated type shared between multiple tables, the type should
be associated directly with the :class:`.MetaData` object; in this
case the type will only be created at the metadata level, or if
created directly. The rules for create/drop of
Postgresql enumerated types have been highly reworked in general.
fixes #3319
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
:meth:`.QueryEvents.before_compile` event allows the creation
of functions which may place additional modifications to
:class:`.Query` objects before the construction of the SELECT
statement. It is hoped that this event be made much more
useful via the advent of a new inspection system that will
allow for detailed modifications to be made against
:class:`.Query` objects in an automated fashion.
fixes #3317
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
is used with a one-to-many query that also features LIMIT,
OFFSET, or DISTINCT has been disabled in the case of a one-to-one
relationship, that is a one-to-many with
:paramref:`.relationship.uselist` set to False. This will produce
more efficient queries in these cases.
fixes #3249
|
| |
| |
| |
| |
| |
| |
| | |
attached to session X" would fail to prevent the object from
also being attached to the new session, in the case that execution
continued after the error raise occurred.
fixes #3301
|
| |
| |
| |
| |
| |
| |
| | |
of a declarative inheritance hierarchy would prevent attributes
and configuration being correctly propagated from the base class
to the inheriting class.
fixes #3219 fixes #3240
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | | |
https://bitbucket.org/iurisilvio/sqlalchemy into pr45
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
https://bitbucket.org/groner/sqlalchemy into pr42
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
From https://www.sqlite.org/partialindex.html
> Partial indexes have been supported in SQLite since version 3.8.0.
Reflection does not expose the predicate of partial indexes. The
postgresql dialect does detect such indexes and issue a warning. I
looked into matching this level of support, but the sqlite pragma
index_info does not expose the predicate. Getting this data would
probably require parsing the CREATE INDEX statement from sqlite_master.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
basically by caching them.
- improve LRUCache so that size management only proceeds
in one thread, add a real get() method
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
for the slots-based __getattr__ thing getting hit
|
| | | |
| | | |
| | | |
| | | |
| | | | |
- replace force_result_map with a mini-API for nested result sets, add
coverage
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | |
|
|\ \ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
For versions > 1.10.1 pg8000 returns de-serialized JSON objects rather
than a string. SQL parameters are still strings though.
|