delta/python-packages/sqlalchemy.git/test/orm, branch setinputsizes_oracle_string

Merge "Check for column object in eval_none, not propkey"

2017-07-19T20:21:57+00:00

Check for column object in eval_none, not propkey

2017-07-18T19:04:36+00:00

Fixed bug involving JSON NULL evaluation logic added in 1.1 as part
of :ticket:`3514` where the logic would not accommodate ORM
mapped attributes named differently from the :class:`.Column`
that was mapped.

Change-Id: I1848afcfb63ad7f074f315d8d3097666069b42be
Fixes: #4031

Check for non-entity when inspecting for subqueryload

2017-07-18T19:02:39+00:00

Fixed issue where adding additional non-entity columns to
a query that includes an entity with subqueryload relationships
would fail, due to an inspection added in 1.1.11 as a result of
:ticket:`4011`.

Change-Id: I8ef082be649125bdc07b428cb9b0a77a65d73671
Fixes: #4033

Support state expiration for with_expression(); rename deferred_expression

2017-06-26T17:49:49+00:00

The attributeimpl for a deferred_expression does not
support a scalar loader, add new configurability so that
the impl can have this flag turned off.   Document
that the with_expression() system currently does not
offer any deferred loading.

To eliminate confusion over "deferred", which refers to
lazy loading of column attributes, and "with_expression",
which refers to an attribute that is explicitly at
query time only, rename deferred_expression to query_expression.

Change-Id: I07c4a050ed68c79ccbde9492e9de1630b7470d74

Add ad-hoc mapped expressions

2017-06-19T21:41:39+00:00

Added a new feature :func:`.orm.with_expression` that allows an ad-hoc
SQL expression to be added to a specific entity in a query at result
time.  This is an alternative to the SQL expression being delivered as
a separate element in the result tuple.

Change-Id: Id8c479f7489fb02e09427837c59d1eabb2a6c014
Fixes: #3058

Merge "Add all versioning logic to _post_update()"

2017-06-16T20:41:14+00:00

Set complete FROM list for subquery eagerload's orig query

2017-06-16T17:02:31+00:00

Instead of checking that the "orig_entity" we receive applies
as a correct FROM element for the subquery we're building,
set the FROM clause of the query to exactly what it already
is based on column_descriptions (assuming there is no FROM
list already), thereby ensuring that the FROM list will remain
intact, regardless of what orig_entity turns out to be and
what the target_cols ultimately refer towards.

Fixed issue with subquery eagerloading which continues on from
the series of issues fixed in :ticket:`2699`, :ticket:`3106`,
:ticket:`3893` involving that the "subquery" contains the correct
FROM clause when beginning from a joined inheritance subclass
and then subquery eager loading onto a relationship from
the base class, while the query also includes criteria against
the subclass. The fix in the previous tickets did not accommodate
for additional subqueryload operations loading more deeply from
the first level, so the fix has been further generalized.

Change-Id: Ic909590814f71e577d8266b1dbc4c393dc48e019
Fixes: #4011

Add all versioning logic to _post_update()

2017-06-15T22:58:29+00:00

An UPDATE emitted as a result of the
:paramref:`.relationship.post_update` feature will now integrate with
the versioning feature to both bump the version id of the row as well
as assert that the existing version number was matched.

Fixes: #3496
Change-Id: I865405dd6069f1c1e3b0d27a4980e9374e059f97

- remove redundant fixture from base test class

2017-06-15T20:07:06+00:00

Change-Id: I76f197d5b2b39ae476bfff924e899773aa123be0

- ensure String has a length for mysql compatibility

2017-06-15T17:51:14+00:00

Change-Id: Iaa1077ca5929bdc67300cc6bfb1ba98aff382246