| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
This is an old parameter no longer relevant to how SQLAlchemy
works, once the Query object was introduced. By deprecating it
we establish that we aren't supporting non-working use cases
and that we encourage applications to move off of the use of this
parameter.
Fixes: #3394
Change-Id: I25b9a38142a1537bbcb27d3e8b66a8b265140072
|
| |
|
|
|
|
|
|
| |
Fixed bug where in Py2K a unicode literal would not be accepted as the
string name of a class or other argument within declarative using
:func:`.backref` on :func:`.relationship`.
amends commit e6f67f48054d906856f879bc1803ea639aa4b670
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"auto increment" column has been changed, such that autoincrement
is no longer implicitly enabled for a :class:`.Table` that has a
composite primary key. In order to accommodate being able to enable
autoincrement for a composite PK member column while at the same time
maintaining SQLAlchemy's long standing behavior of enabling
implicit autoincrement for a single integer primary key, a third
state has been added to the :paramref:`.Column.autoincrement` parameter
``"auto"``, which is now the default. fixes #3216
- The MySQL dialect no longer generates an extra "KEY" directive when
generating CREATE TABLE DDL for a table using InnoDB with a
composite primary key with AUTO_INCREMENT on a column that isn't the
first column; to overcome InnoDB's limitation here, the PRIMARY KEY
constraint is now generated with the AUTO_INCREMENT column placed
first in the list of columns.
|
| |
|
|
|
|
|
|
|
| |
a column setup on the ABC base which had a different attribute
name vs. column name would not be correctly mapped on the final
base class. The failure on 0.9 would be silent whereas on
1.0 it raised an ArgumentError, so may not have been noticed
prior to 1.0.
fixes #3480
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
event where its invocation was moved to be after the class manager's
instrumentation of the class, which is the opposite of what the
documentation for the event explicitly states. The rationale for the
switch was due to Declarative taking the step of setting up
the full "instrumentation manager" for a class before it was mapped
for the purpose of the new ``@declared_attr`` features
described in :ref:`feature_3150`, but the change was also made
against the classical use of :func:`.mapper` for consistency.
However, SQLSoup relies upon the instrumentation event happening
before any instrumentation under classical mapping.
The behavior is reverted in the case of classical and declarative
mapping, the latter implemented by using a simple memoization
without using class manager.
fixes #3388
|
| |
|
|
|
|
| |
and ``__declare_last__`` accessors where these would no longer be
called on the superclass of the declarative base.
fixes #3383
|
| |
|
|
|
|
|
|
|
|
| |
and :class:`.CheckConstraint` has been further enhanced such that
when the constraint is associated with non-table-bound :class:`.Column`
objects, the constraint will set up event listeners with the
columns themselves such that the constraint auto attaches at the
same time the columns are associated with the table. This in particular
helps in some edge cases in declarative but is also of general use.
fixes #3341
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
subclass, the value returned by the descriptor is not available
because the superclass is already mapped with the InstrumentedAttribute,
until the subclass is mapped. We add a setattr() to set up that
attribute so that the __mapper_args__ hook and possibly others
have access to the "cascaded" version of the attribute within
the call.
|
| |
|
|
|
|
| |
when using :class:`.AbstractConcreteBase` in conjunction with
a subclass that declares ``__abstract__``.
fixes #3185
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that are now affixed to _MapperConfig
- declarative now creates column copies ahead of time
so that they are ready to go for a declared_attr
- overhaul of declared_attr; memoization, cascading modifier
- A relationship set up with :class:`.declared_attr` on
a :class:`.AbstractConcreteBase` base class will now be configured
on the abstract base mapping automatically, in addition to being
set up on descendant concrete classes as usual.
fixes #2670
- The :class:`.declared_attr` construct has newly improved
behaviors and features in conjunction with declarative. The
decorated function will now have access to the final column
copies present on the local mixin when invoked, and will also
be invoked exactly once for each mapped class, the returned result
being memoized. A new modifier :attr:`.declared_attr.cascading`
is added as well. fixes #3150
- the original plan for #3150 has been scaled back; by copying
mixin columns up front and memoizing, we don't actually need
the "map properties later" thing.
- full docs + migration notes
|
| | |
|
| |
|
|
|
|
|
| |
distinguished for when it was actually the value ``False``.
The ``__abstract__`` flag needs to acutally evaluate to a True
value at the level being tested.
fixes #3097
|
| |
|
|
|
|
|
|
|
|
| |
mapper is implicitly combining one of its column-based attributes
with that of the parent, where those columns normally don't necessarily
share the same value. This is an extension of an existing check that
was added via :ticket:`1892`; however this new check emits only a
warning, instead of an exception, to allow for applications that may
be relying upon the existing behavior.
fixes #3042
|
| |
|
|
|
|
|
|
|
| |
mixin or abstract class when accessed, so that modifications made
to this dictionary by declarative itself won't conflict with that
of other mappings. The dictionary is modified regarding the
``version_id_col`` and ``polymorphic_on`` arguments, replacing the
column within with the one that is officially mapped to the local
class/table. fixes #3062
|
| |
|
|
| |
Found using: https://github.com/intgr/topy
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
target of :paramref:`.relationship.secondary` for the purposes
of creating very complex :func:`.relationship` join conditions.
The change includes adjustments to query joining, joined eager loading
to not render a SELECT subquery, changes to lazy loading such that
the "secondary" target is properly included in the SELECT, and
changes to declarative to better support specification of a
join() object with classes as targets.
|
| |
|
|
|
|
|
|
|
|
| |
:class:`.DeferredReflection`
to define classes pending for reflection, if some subset of those
classes were discarded before the :meth:`.DeferredReflection.prepare`
method were called to reflect and map the class, a strong reference
to the class would remain held within the declarative internals.
This internal collection of "classes to map" now uses weak
references against the classes themselves.
|
| |
|
|
|
|
|
|
|
|
|
| |
attribute on declarative to simply refer directly to an :class:`.InstrumentedAttribute`
on a superclass or on the class itself, and it
acts more or less like a synonym; in 0.9, this fails to set up enough
bookkeeping to keep up with the more liberalized backref logic
from :ticket:`2789`. Even though this use case was never directly
considered, it is now detected by declarative at the "setattr()" level
as well as when setting up a subclass, and the mirrored/renamed attribute
is now set up as a :func:`.synonym` instead. [ticket:2900]
|
| |
|
|
|
|
|
| |
:class:`.Column` is mapped multiple times under different properties
(which typically should be a :func:`.synonym` instead) or if two
or more :class:`.Column` objects are given the same name, raising
a warning if this condition is detected. [ticket:2828]
|
| |
|
|
|
|
|
| |
doesn't resolve to a class or mapper has been corrected to work
the same way as when a non-string arg is received, which indicates
the name of the relationship which had the configurational error.
[ticket:2888]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
automatic reflection support for the "secondary" table referred
to by a :func:`.relationship`. "secondary", when specified
either as a string table name, or as a :class:`.Table` object with
only a name and :class:`.MetaData` object will also be included
in the reflection process when :meth:`.DeferredReflection.prepare`
is called. [ticket:2865]
- clsregistry._resolver() now uses a stateful _class_resolver()
class in order to handle the work of mapping strings to
objects. This is to provide for simpler extensibility, namely
a ._resolvers collection of ad-hoc name resolution functions;
the DeferredReflection class adds its own resolver here in order
to handle relationship(secondary) names which generate new
Table objects.
|
| |
|
|
|
| |
as the string name of a class or other argument within
declarative using :func:`.relationship`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead of relying upon various ``quote=True`` flags being passed around,
these flags are converted into rich string objects with quoting information
included at the point at which they are passed to common schema constructs
like :class:`.Table`, :class:`.Column`, etc. This solves the issue
of various methods that don't correctly honor the "quote" flag such
as :meth:`.Engine.has_table` and related methods. The :class:`.quoted_name`
object is a string subclass that can also be used explicitly if needed;
the object will hold onto the quoting preferences passed and will
also bypass the "name normalization" performed by dialects that
standardize on uppercase symbols, such as Oracle, Firebird and DB2.
The upshot is that the "uppercase" backends can now work with force-quoted
names, such as lowercase-quoted names and new reserved words.
[ticket:2812]
|
| |
|
|
|
|
|
|
|
| |
- rework the event system so that event modules load after their
targets, dependencies are reversed
- create an improved strategy lookup system for the ORM
- rework the ORM to have very few import cycles
- move out "importlater" to just util.dependency
- other tricks to cross-populate modules in as clear a way as possible
|
| |
|
|
|
|
| |
by name in a string argument used with ``order_by``,
``primaryjoin``, or similar in :func:`.relationship`,
in addition to column-bound attributes. [ticket:2761]
|
| | |
|
| |
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
where since it considers the current class' ``__table__``, was
sensitive to when it was called. This is 0.7's behavior also,
but in 0.7 things tended to "work out" within events like
``__mapper_args__()``. :func:`.has_inherited_table` now only
considers superclasses, so should return the same answer
regarding the current class no matter when it's called
(obviously assuming the state of the superclass).
[ticket:2656]
|
| | |
|
| |
|
|
|
|
| |
store ModuleMarkers for multiple roots, one for each token in a
module path. this allows partial path resolution.
- docs to this effect
|
| |
|
|
|
|
|
| |
become an externally usable package but still remains within the main sqlalchemy parent package.
in this system, we use kind of an ugly hack to get the noseplugin imported outside of the
"sqlalchemy" package, while still making it available within sqlalchemy for usage by
third party libraries.
|
| |
|
|
|
|
|
|
|
|
|
| |
between a @declared_attr Column and a
directly-defined Column on a mixin. In both
cases, the Column will be applied to the
declared class' table, but not to that of a
joined inheritance subclass. Previously,
the directly-defined Column would be placed
on both the base and the sub table, which isn't
typically what's desired. [ticket:2565]
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
attributes that are not Column or MapperProperty;
including any user-defined value as well
as association proxy objects. [ticket:2517]
|
| |
|
|
|
|
|
| |
single-inheritance declarative subclasses,
with or without using a mixin, can be resolved
using a new @declared_attr usage described
in the documentation. [ticket:2472]
|
| | |
|
| |
|
|
|
|
|
|
| |
declared on a single-table inheritance subclass
up to the parent class' table, when the parent
class is itself mapped to a join() or select()
statement, directly or via joined inheritane,
and not just a Table. [ticket:2549]
|
| | |
|
|
|
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.
|