| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
This feature is now turned off by default.
|
| |
|
|
|
|
| |
identity
isn't appended to the list. reflection makes use of this.
|
| |
|
|
|
|
|
|
|
| |
caused a user-provided "getter" to no longer receive values of ``None``
when fetching scalar values from a target that is non-present. The
check for None introduced by this change is now moved into the default
getter, so a user-provided getter will also again receive values of
None.
re: #2810
|
| |
|
|
|
|
| |
refreshed with current names, so that an ``import *`` from this
module again works.
fixes #2975
|
| |
|
|
|
|
|
|
|
| |
a no-name :class:`.BindParameter` is received, e.g. via :func:`.sql.literal`
or similar; the "key" of the bind param is used as the key within
.c. rather than the rendered name. Since these binds have "anonymous"
names in any case, this allows individual bound parameters to
have their own name within a selectable if they are otherwise unlabeled.
fixes #2974
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
when presented with duplicate columns. The behavior of emitting a
warning and replacing the old column with the same name still
remains to some degree; the replacement in particular is to maintain
backwards compatibility. However, the replaced column still remains
associated with the ``c`` collection now in a collection ``._all_columns``,
which is used by constructs such as aliases and unions, to deal with
the set of columns in ``c`` more towards what is actually in the
list of columns rather than the unique set of key names. This helps
with situations where SELECT statements with same-named columns
are used in unions and such, so that the union can match the columns
up positionally and also there's some chance of :meth:`.FromClause.corresponding_column`
still being usable here (it can now return a column that is only
in selectable.c._all_columns and not otherwise named).
The new collection is underscored as we still need to decide where this
list might end up. Theoretically it
would become the result of iter(selectable.c), however this would mean
that the length of the iteration would no longer match the length of
keys(), and that behavior needs to be checked out.
fixes #2974
- add a bunch more tests for ColumnCollection
|
| |
|
|
|
|
| |
of columns given positionally would not be preserved. This could
have potential impact in positional situations such as applying the
resulting :class:`.TextAsFrom` object to a union.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
constructs has been enhanced in order to assist with existing
schemes that rely upon addition of ad-hoc keyword arguments to
constructs.
- To suit the use case of allowing custom arguments at construction time,
the :meth:`.DialectKWArgs.argument_for` method now allows this registration.
fixes #2962
|
| |
|
|
|
|
|
|
| |
level (e.g. on the :class:`.Mapper` or :class:`.ClassManager`
level, as opposed to on an individual mapped class, and also on
:class:`.Connection`) that also made use of internal argument conversion
(which is most within those categories) would fail to be removable.
fixes #2973
|
| |
|
|
|
|
|
| |
:func:`.orm.lazyload` with the "wildcard" expression, e.g. ``"*"``,
would raise an assertion error in the case where the query didn't
contain any actual entities. This assertion is meant for other cases
and was catching this one inadvertently.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
implemented right before the release of 0.9.3 affected the case where
a UNION contained nested joins in it. "Join rewriting" is a feature
with a wide range of possibilities and is the first intricate
"SQL rewriting" feature we've introduced in years, so we're sort of
going through a lot of iterations with it (not unlike eager loading
back in the 0.2/0.3 series, polymorphic loading in 0.4/0.5). We should
be there soon so thanks for bearing with us :).
fixes #2969 re: #2967
- solve the issue of join rewriting inspecting various types of
from objects without using isinstance(), by adding some new
underscored inspection flags to the FromClause hierarchy.
|
| | |
|
| |
|
|
|
|
| |
"could not send data to server", which complements the existing
"could not receive data from server" and has been observed by users,
fixes #2936
|
| |
|
|
|
| |
on the columns clause of the SELECT statement if the targets were
aliased tables, as opposed to individual aliased columns.
|
| |
|
|
|
| |
would fail to be rewritten properly, such as when the exists is
mapped to a column_property in an intricate nested-join scenario. #2967
|
| |
|
|
| |
for output consistency within the tests as well as in practice
|
| |
|
|
| |
is done
|
| |
|
|
|
|
|
| |
fractional seconds support; also added fractional seconds support
to :class:`.mysql.TIMESTAMP`. DBAPI support is limited, though
fractional seconds are known to be supported by MySQL Connector/Python.
Patch courtesy Geert JM Vanderkelen. #2941
|
| |\
| |
| |
| | |
into t
|
| | | |
|
| | |
| |
| |
| |
| | |
or tuple would raise an IndexError. It now produces an empty
insert construct as would be the case with an empty dictionary.
|
| | |
| |
| |
| |
| |
| | |
concurrent ability to return connections from the pool means that the
"first_connect" event is now no longer synchronized either, thus leading
to dialect mis-configurations under even minimal concurrency situations.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(pre 8.1) versions of Postgresql, and potentially other PG engines
such as Redshift (assuming Redshift reports the version as < 8.1).
The query for "indexes" as well as "primary keys" relies upon inspecting
a so-called "int2vector" datatype, which refuses to coerce to an array
prior to 8.1 causing failures regarding the "ANY()" operator used
in the query. Extensive googling has located the very hacky, but
recommended-by-PG-core-developer query to use when PG version < 8.1
is in use, so index and primary key constraint reflection now work
on these versions.
|
| | | |
|
| | |
| |
| |
| | |
both _resolve_type_affinity() directly as well as round trip tests fully.
|
| | |
| |
| |
| |
| |
| | |
types; such as if it encounters a string like ``INTEGER(5)``, the
:class:`.INTEGER` type will be instantiated without the "5" being included,
based on detecting a ``TypeError`` on the first attempt.
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
SQLite allows column types that aren't technically understood in sqlite
by using 'data affinity', which is an algorithm for converting column
types in to some sort of useful type that can be stored and retrieved
from the db. Unfortunatly, this breaks reflection since we (previously)
expected a sqlite db to reflect column types that we permit in the
`ischema_names` for that dialect.
This patch changes the logic for 'unknown' column types during
reflection to instead run through SQLite's data affinity algorithm, and
assigns appropriate types from that.
It also expands the matching for column type to include column types
with spaces (strongly discouraged but allowed by sqlite) and also
completely empty column types (in which case the NullType is assigned,
which sqlite will treat as a Blob - or rather, Blob is treated as
NullType). These changes mean that SQLite will never raise an error for
an unknown type during reflection - there will always be some 'useful'
type returned, which follows the spirit of SQLite (accomodation before
sanity!).
|
| | | | |
|
| |\ \ \
| | | |
| | | | |
python_type for ARRAY (PGArray)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
about non-equality operators in general.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
sections
- convert all paramter references in relationship documentation to :paramref:
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
hstore extension. #2959
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
- clarify section on "foreign key reflection" and group this in a
section that refers to foreign keys.
|
| | | | |
| | | |
| | | |
| | | | |
- trim off fn prefix on some relationship parameter names
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
query for "show standard_conforming_strings"; as this variable was
added as of PG 8.2, we skip the query for PG versions older than
that as well as for backends like Redshift. #2946
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
reflection query were updated to take into account primary key constraints
that were renamed; the newer query fails on very old versions of
Postgresql such as version 7, so the old query is restored in those cases
when server_version_info < (8, 0) is detected. #2291
|
| | |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
erroneously passed a column expression whose comparator included
the ``__getitem__()`` method, such as a column that uses the
:class:`.postgresql.ARRAY` type. [ticket:2957]
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
fully usable within declarative relationship configuration, as its
string classname would not be available in the registry of classnames
at mapper configuration time. The class now explicitly adds itself
to the class regsitry, and additionally both :class:`.AbstractConcreteBase`
as well as :class:`.ConcreteBase` set themselves up *before* mappers
are configured within the :func:`.configure_mappers` setup, using
the new :meth:`.MapperEvents.before_configured` event. [ticket:2950]
- Added new :meth:`.MapperEvents.before_configured` event which allows
an event at the start of :func:`.configure_mappers`, as well
as ``__declare_first__()`` hook within declarative to complement
``__declare_last__()``.
- modified how after_configured is invoked; we just make a dispatch()
not actually connected to any mapper. this makes it easier
to also invoke before_configured correctly.
- improved the ComparableEntity fixture to handle collections that are sets.
|
| | | |
| | |
| | |
| | | |
Closes #2934
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Have also considered linking column.label() to the "column" itself being
in the result map but this reveals some naming collision problems (that
also seem to be very poorly tested...). This should be as far as
we want to go right now with [ticket:2932].
|