| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
Found using: https://github.com/intgr/topy
|
| |
|
|
|
|
|
| |
not be created between two classes that are in a joined inheritance
relationship, for those foreign keys that link the subclass back to
the superclass.
fixes #3004
|
| |
|
|
|
|
| |
:func:`.attributes.flag_modified` where the change event would not be
propagated if the attribute had been reassigned to itself.
fixes #2997
|
| |
|
|
| |
(e.g. ``x[:] = [...]``) would fail on Py3k.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is currently being supported in addition to nose, and will likely
be preferred to nose going forward. The nose plugin system used
by SQLAlchemy has been split out so that it works under pytest as
well. There are no plans to drop support for nose at the moment
and we hope that the test suite itself can continue to remain as
agnostic of testing platform as possible. See the file
README.unittests.rst for updated information on running tests
with pytest.
The test plugin system has also been enhanced to support running
tests against mutiple database URLs at once, by specifying the ``--db``
and/or ``--dburi`` flags multiple times. This does not run the entire test
suite for each database, but instead allows test cases that are specific
to certain backends make use of that backend as the test is run.
When using pytest as the test runner, the system will also run
specific test suites multiple times, once for each database, particularly
those tests within the "dialect suite". The plan is that the enhanced
system will also be used by Alembic, and allow Alembic to run
migration operation tests against multiple backends in one run, including
third-party backends not included within Alembic itself.
Third party dialects and extensions are also encouraged to standardize
on SQLAlchemy's test suite as a basis; see the file README.dialects.rst
for background on building out from SQLAlchemy's test platform.
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
new automap extension would fail if classes
were pre-arranged in single or potentially joined inheritance patterns.
The repaired joined inheritance issue could also potentially apply when
using :class:`.DeferredReflection` as well.
|
| |
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
|
|
| |
correctly with table or column names that contain non-ASCII
characters. [ticket:2869]
|
| |
|
|
|
|
|
|
| |
itself
around for a long time
- association proxy now returns None for proxied scalar that is also None, rather
than raising AttributeError. [ticket:2810]
|
| |
|
|
|
| |
"serializer" can just be ditched, or if somehow these deterministic issues
can be fixed (everyone implements __reduce__ maybe?)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
unittest.TestCase
|
| | |
|
| |
|
|
|
| |
compilation rule which allows skipping of columns, by producing
a rule that returns ``None``. Also in 0.8.3.
|
| |
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
| |
proxies, they aren't overriding getattr() or setattr() at all. so all the
hardcoded getattr()/setattr() is removed from collections.py. Lots of these
getattr/setattr were against the attributeimpl and decorated functions
and don't seem like they'd ever be needed; for a user that needs special access
to a collection, we can evaulate that use case and add a single point of
"unwrapping", and probably add a hook for it via
InstrumentationManager so that the collection implementation isn't complicated
by it.
|
| |
|
|
|
|
| |
by name in a string argument used with ``order_by``,
``primaryjoin``, or similar in :func:`.relationship`,
in addition to column-bound attributes. [ticket:2761]
|
| |
|
|
| |
- simplify
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
scalar values, for comparisons to None to also take into account
the association record itself being non-present, in addition to the
existing test for the scalar endpoint on the association record
being NULL. Previously, comparing ``Cls.scalar == None`` would return
records for which ``Cls.associated`` were present and
``Cls.associated.scalar`` is None, but not rows for which
``Cls.associated`` is non-present. More significantly, the
inverse operation ``Cls.scalar != None`` *would* return ``Cls``
rows for which ``Cls.associated`` was non-present.
Additionally, added a special use case where you
can call ``Cls.scalar.has()`` with no arguments,
when ``Cls.scalar`` is a column-based value - this returns whether or
not ``Cls.associated`` has any rows present, regardless of whether
or not ``Cls.associated.scalar`` is NULL or not.
[ticket:2751]
|
| |
|
|
|
| |
when ``clear()`` was called.
[ticket:2730]
|
| | |
|
| |
|
|
|
|
| |
reason py3k's pickle seems to be OK? not sure why that is, as this
is all related to http://bugs.python.org/issue998998
|
| |\ |
|
| | | |
|
| |/
|
|
| |
- went through examples/ and cleaned out excess list() calls
|
| |
|
|
|
|
|
| |
that the "id" passed from the pickler is turned into a string
to prevent against bytes being parsed on Py3K, as well as that
``relationship()`` and ``orm.join()`` constructs are now properly
serialized. [ticket:2698] and some other observed issues.
|
| | |
|
| |
|
|
|
| |
now without strong ref on the parent
- fix message compare for py3k
|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
:meth:`.MutableBase.coerce` method to be used, even though
the code seemed to indicate this intent, so this now works
and a brief example is added. As a side-effect,
the mechanics of this event handler have been changed so that
new :class:`.MutableComposite` types no longer add per-type
global event handlers. Also in 0.7.10
[ticket:2624]
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
store ModuleMarkers for multiple roots, one for each token in a
module path. this allows partial path resolution.
- docs to this effect
|
| |
|
|
|
|
|
|
|
|
|
| |
to :class:`.Engine`. This method works similarly to
:class:`.Connection.execution_options` in that it creates
a copy of the parent object which will refer to the new
set of options. The method can be used to build
sharding schemes where each engine shares the same
underlying pool of connections. The method
has been tested against the horizontal shard
recipe in the ORM as well.
|
| |
|
|
|
|
|
| |
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.
|