| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the vast majority of file lines are spent on documentation, which moves
into package __init__. The core declarative idea lives in base and
is back down to its originally low size of under 500 lines. The various
helpers and such move into api.py, and the full span of string lookup
moves into a new module clsregistry. the rest of declarative only
refers to two functions in clsregistry in three places inside of base.
- [feature] Declarative now maintains a registry
of classes by string name as well as by full
module-qualified name. Multiple classes with the
same name can now be looked up based on a module-qualified
string within relationship(). Simple class name
lookups where more than one class shares the same
name now raises an informative error message.
[ticket:2338]
- lots of tests to ensure the new weak referencing memory management
is maintained by the new class registry system. this ticket was
served very well by waiting to do #2526 first, else this would
have needed to be rewritten anyway.
|
| |
|
| |
|
|
|
|
| |
- split out test_declarative into four separate modules
|
|
|
|
| |
- add foreign, remote annotations to declarative
|
|
|
|
|
|
| |
using an already instrumented column from a
superclass as "polymorphic_on" failed to resolve
the underlying Column. [ticket:2345]
|
|
|
|
|
| |
declarative_base(). Allows two or more declarative
bases to share the same registry of class names.
|
|
|
|
|
|
| |
an empty tuple as well as an empty dict.
[ticket:2339]. Thanks to Fayaz Yusuf Khan
for the patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
against ORM-level column could be treated as
a distinct entity when producing certain
kinds of joined-inh joins. [ticket:2316]
- [bug] related to [ticket:2316], made some
adjustments to the change from [ticket:2261]
regarding the "from" list on a select(). The
_froms collection is no longer memoized, as this
simplifies various use cases and removes the
need for a "warning" if a column is attached
to a table after it was already used in an
expression - the select() construct will now
always produce the correct expression.
There's probably no real-world
performance hit here; select() objects are
almost always made ad-hoc, and systems that
wish to optimize the re-use of a select()
would be using the "compiled_cache" feature.
A hit which would occur when calling select.bind
has been reduced, but the vast majority
of users shouldn't be using "bound metadata"
anyway :).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
using concrete inheritance in conjunction with
the new ConcreteBase or AbstractConcreteBase
would fail to apply the subclasses deeper than
one level to the "polymorphic loader" of each
base [ticket:2312]
- [bug] Fixed bug whereby a subclass of a subclass
using the new AbstractConcreteBase would fail
to acquire the correct "base_mapper" attribute
when the "base" mapper was generated, thereby
causing failures later on. [ticket:2312]
|
| |
|
|
|
|
| |
does not propagate to subclasses. [ticket:2283]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Called after a configure() step has completed and
mappers were in fact affected. Theoretically this
event is called once per application, unless new mappings
are constructed after existing ones have been used
already.
- New declarative features:
- __declare_last__() method, establishes an event
listener for the class method that will be called
when mappers are completed with the final "configure"
step.
- __abstract__ flag. The class will not be mapped
at all when this flag is present on the class.
- New helper classes ConcreteBase, AbstractConcreteBase.
Allow concrete mappings using declarative which automatically
set up the "polymorphic_union" when the "configure"
mapper step is invoked.
- The mapper itself has semi-private methods that allow
the "with_polymorphic" selectable to be assigned
to the mapper after it has already been configured.
[ticket:2239]
|
|
|
|
|
|
|
|
|
| |
ForeignKeyConstraint refers to a column name in
the parent that is not found. Also in 0.6.9.
- add tests for [ticket:2226], as if we hit each @declared_attr
directly with obj.__get__(obj, name) instead of using
getattr(cls, name). Basic inheritance mechanics are improperly
used in this case, so 2226 is invalid.
|
|
|
|
|
|
| |
from a superclass of the same name would fail
due to an unnecessary lookup of the name
in the _decl_class_registry. [ticket:2194]
|
| |
|
|
|
|
|
|
|
| |
classes to a new test.lib.fixtures module
- move testing.TestBase to test.lib.fixtures
- massive search and replace
|
|
|
|
| |
See #2088.
|
| |
|
|
|
|
|
| |
aren't mistaken for always-hashable, possibly-column
arguments. [ticket:2091]
|
|
|
|
| |
tuple is now optional. [ticket:1468]
|
| |
|
|
|
|
|
|
|
|
| |
Column objects placed inline would fail
to initialize. The Column objects can now
be inline with the composite() or external
and pulled in via name or object ref.
[ticket:2058]
|
|
|
|
|
| |
'metadata' is used for a column attribute on a
declarative class. [ticket:2050]
|
|
|
|
|
|
|
| |
would have no 'polymorphic_on' column if it didn't also
specify a 'polymorphic_identity', leading to strange
errors upon refresh, wrong class loaded when querying
from that target. [ticket:2038]
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
outside of "sqlalchemy" and under "test/".
Rationale:
- coverage plugin works without issue, without need for an awkward
additional package install
- command line for "nosetests" isn't polluted with SQLAlchemy options
[ticket:1949]
|
| |\ |
|
| | | |
|
|\ \ \ |
|
| |\ \ \
| | | |/
| | |/| |
|
| | |/
| |/| |
|
|\ \ \ |
|
| |\ \ \
| | | |/
| | |/| |
|
| | |/
| |/| |
|
|\ \ \ |
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
reverse order of which they were added to the property. A
typical effect of this is that the ".id" attribute on a
joined-inheritance subclass, where both parent/child tables
name the PK column ".id", will reference the ".id" column of
the child table, not the parent, thus allowing join conditions
and such to be constructed more intuitively. This is a
behavior change for some joined-table inheritance queries.
[ticket:1892]
- it's now an error condition to map to a join where multiple
same-named columns from each table combine themselves
implicitly. An explicit mention in the "properties" dictionary
should be specified, using a list of columns, or
column_property(*cols) with declarative. [ticket:1892]
|
|/ / |
|
|/
|
|
| |
or dict format, and is not None. [ticket:1972]
|
|
|
|
|
| |
a column of the same name associated with a superclass.
Thanks to Oystein Haaland.
|
| |
|
|
|
|
|
|
|
|
|
| |
prop.columns.append(col)
logic when columns are present in a joined subclass with an attribute name different
than the column name itself [ticket:1931]
- add coverage to verify that we need to check (obj.name or name) when
deciding if a Column from a mixin should be added to the mapped table
|
|
|
|
|
|
|
| |
correctly to a single-table inheritance scheme where
the attribute name is different than that of the column.
[ticket:1930]. Note [ticket:1931] which is the same
issue for joined inh, not yet resolved.
|
| |
|
|
|
|
|
|
|
| |
with declarative is sqlalchemy.ext.declarative.mapperproperty.
Same thing, but moving there since it is more of a
"marker" that's specific to declararative,
not just an attribute technique. [ticket:1915]
|
|
|
|
|
|
| |
__mapper_args__, __table_args__, __tablename__ on
a base class that is not a mixin, as well as mixins.
[ticket:1922]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The exception raised by Session when it is used
subsequent to a subtransaction rollback (which is what
happens when a flush fails in autocommit=False mode) has
now been reworded (this is the "inactive due to a
rollback in a subtransaction" message). In particular,
if the rollback was due to an exception during flush(),
the message states this is the case, and reiterates the
string form of the original exception that occurred
during flush. If the session is closed due to explicit
usage of subtransactions (not very common), the message
just states this is the case.
- The exception raised by Mapper when repeated requests to
its initialization are made after initialization already
failed no longer assumes the "hasattr" case, since
there's other scenarios in which this message gets
emitted, and the message also does not compound onto
itself multiple times - you get the same message for
each attempt at usage. The misnomer "compiles" is being
traded out for "initialize".
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to mapper() now accept Column objects as members in
addition to strings. This so that same-named Column
objects, such as those within a join(), can be
disambiguated.
- A warning is now emitted if a mapper is created against a
join or other single selectable that includes multiple
columns with the same name in its .c. collection,
and those columns aren't explictly named as part of
the same or separate attributes (or excluded).
In 0.7 this warning will be an exception. Note that
this warning is not emitted when the combination occurs
as a result of inheritance, so that attributes
still allow being overridden naturally.
[ticket:1896]. In 0.7 this will be improved further.
- The primary_key argument to mapper() can now specify
a series of columns that are only a subset of
the calculated "primary key" columns of the mapped
selectable, without an error being raised. This
helps for situations where a selectable's effective
primary key is simpler than the number of columns
in the selectable that are actually marked as
"primary_key", such as a join against two
tables on their primary key columns [ticket:1896].
|
|
|
|
| |
would display the wrong name.
|