an "orphan" has been modified to more closely match the
behavior as that of persistent objects, which is that the object
is expunged from the :class:`.Session` as soon as it is
de-associated from any of its orphan-enabled parents. Previously,
the pending object would be expunged only if de-associated
from all of its orphan-enabled parents. The new flag ``legacy_is_orphan``
is added to :func:`.orm.mapper` which re-establishes the
legacy behavior. [ticket:2655]
method, which fires off each time the collection is associated
or de-associated with a mapped object - the decorator
was not tested or functional. The decorator method
is now named :meth:`.collection.linker` though the name "link"
remains for backwards compatibility. Courtesy Luca Wehrstedt.
[ticket:2653]
collections, mainly that the usage of the @collection decorators
will now honor the __mro__ of the given class, applying the
logic of the sub-most classes' version of a particular collection
method. Previously, it wasn't predictable when subclassing
an existing instrumented class such as :class:`.MappedCollection`
whether or not custom methods would resolve correctly.
[ticket:2654]
- The undocumented (and hopefully unused) system of producing
custom collections using an ``__instrumentation__`` datastructure
associated with the collection has been removed, as this was a complex
and untested feature which was also essentially redundant versus the
decorator approach. Other internal simplifcations to the
orm.collections module have been made as well.
functions, in addition to straight columns. Common modifiers
include using ``somecolumn.desc()`` for a descending index and
``func.lower(somecolumn)`` for a case-insensitive index, depending on the
capabilities of the target backend.
[ticket:695]
- Fixed potential memory leak which could occur if an
arbitrary number of :class:`.sessionmaker` objects
were created. The anonymous subclass created by
the sessionmaker, when dereferenced, would not be garbage
collected due to remaining class-level references from the
event package. This issue also applies to any custom system
that made use of ad-hoc subclasses in conjunction with
an event dispatcher. Also in 0.7.10. [ticket:2650]
- Fixed a regression whereby the "collation" parameter
of the character types CHAR, NCHAR, etc. stopped working,
as "collation" is now supported by the base string types.
The TEXT, NCHAR, CHAR, VARCHAR types within the
MSSQL dialect are now synonyms for the base types.
- move out the type rendering tests into DB-agnostic tests
and remove some of the old "create" statements. tests here
are still very disorganized.
associated with the ORM or its extensions can be retrieved.
This fulfills the common request of being able to inspect
all :class:`.QueryableAttribute` descriptors in addition to
extension types such as :class:`.hybrid_property` and
:class:`.AssociationProxy`. See :attr:`.Mapper.all_orm_descriptors`.
on regular append/remove history
- fix the real cause of the original #2637 issue, backrefs call upon
the "pop()" method now which wasn't implemented for Dynamic
- Fixes to the "dynamic" loader on :func:`.relationship`, includes
that backrefs will work properly even when autoflush is disabled,
history events are more accurate in scenarios where multiple add/remove
of the same object occurs, as can often be the case in conjunction
with the association proxy. [ticket:2637]
0.7.9, to intercept legacy SQLite quoting characters when reflecting
foreign keys. In addition to intercepting double quotes, other
quoting characters such as brackets, backticks, and single quotes
are now also intercepted. [ticket:2568]
:class:`.CheckConstraint` would apply itself back to the
original table during a :meth:`.Table.tometadata` operation, as
it would parse the SQL expression for a parent table. The
operation now copies the given expression to correspond to the
new table.
[ticket:2633]
to a DBLINK remote database; while the syntax has been present in the
Oracle dialect for some time, up until now it has never been tested.
The syntax has been tested against a sample database linking to itself,
however there's still some uncertainty as to what should be used for the
"owner" when querying the remote database for table information.
Currently, the value of "username" from user_db_links is used to
match the "owner". [ticket:2619]
without passing the "for_update=True" flag would apply the default
object to the server_default, blowing away whatever was there.
The explicit for_update=True argument shouldn't be needed with this usage
(especially since the documentation shows an example without it being
used) so it is now arranged internally using a copy of the given default
object, if the flag isn't set to what corresponds to that argument.
Also in 0.7.10. [ticket:2631]
- update "not supported" messages for empty inserts, mutlivalue inserts
- rework the ValuesBase approach for multiple value sets so that stmt.parameters
does store a list for multiple values; the _has_multiple_parameters flag now indicates
which of the two modes the statement is within. it now raises exceptions if a subsequent
call to values() attempts to call a ValuesBase with one mode in the style of the other
mode; that is, you can't switch a single- or multi- valued ValuesBase to the other mode,
and also if a multiple value is passed simultaneously with a kwargs set.
Added tests for these error conditions
- Calling values() multiple times in multivalue mode now extends the parameter list to
include the new parameter sets.
- add error/test if multiple *args were passed to ValuesBase.values()
- rework the compiler approach for multivalue inserts, back to where
_get_colparams() returns the same list of (column, value) as before, thereby
maintaining the identical number of append() and other calls when multivalue
is not enabled. In the case of multivalue, it makes a last-minute switch to return
a list of lists instead of the single list. As it constructs the additional lists, the inline
defaults and other calculated default parameters of the first parameter
set are copied into the newly generated lists so that these features continue
to function for a multivalue insert. Multivalue inserts now add no additional
function calls to the compilation for regular insert constructs.
- parameter lists for multivalue inserts now includes an integer index for all
parameter sets.
- add detailed documentation for ValuesBase.values(), including careful wording
to describe the difference between multiple values and an executemany() call.
- add a test for multivalue insert + returning - it works !
- remove the very old/never used "postgresql_returning"/"firebird_returning" flags.
to use the cx_Oracle.LOB type when result rows are returned,
so the dialect has been repaired to exclude LONG from
having cx_Oracle.LOB filtering applied. Also in 0.7.10.
[ticket:2620]
cx_Oracle so that a return value of ``False`` will result
in no call to ``connection.commit()``, hence avoiding
"no transaction" errors. Two-phase transactions have
now been shown to work in a rudimental fashion with
SQLAlchemy and cx_oracle, however are subject to caveats
observed with the driver; check the documentation
for details. Also in 0.7.10.
[ticket:2611]
Some databases support this syntax for inserts:
INSERT INTO table (id, name) VALUES
('v1', 'v2'),
('v3', 'v4');
which greatly increases INSERT speed.
It is now possible to pass a list of lists/tuples/dictionaries as
the values param to the Insert construct. We convert it to a flat
dictionary so we can continue using bind params. The above query
will be converted to:
INSERT INTO table (id, name) VALUES
(:id, :name),
(:id0, :name0);
Currently only supported on postgresql, mysql and sqlite.
: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]
- paths now store Mapper + MapperProperty now instead of string key,
so that the parent mapper for the property is known, supports same-named
properties on multiple subclasses
- the Mapper within the path is now always relevant to the property
to the right of it. PathRegistry does the translation now, instead
of having all the outside users of PathRegistry worry about it,
to produce a path that is much more consistent. Paths are now
consistent with mappings in all cases. Special logic to get at
"with_polymorphic" structures and such added also.
- AliasedClass now has two modes, "use_mapper_path" and regular;
"use_mapper_path" is for all those situations where we put an AliasedClass
in for a plain class internally, and want it to "path" with the
plain mapper.
- The AliasedInsp is now the first class "entity" for an AliasedClass,
and is passed around internally and used as attr._parententity
and such. it is the AliasedClass analogue for Mapper.
Audrius Kažukauskas