to a collection-based attribute which already had pending changes
would generate incorrect history [ticket:922]
- fixed delete-orphan cascade bug whereby setting the same
object twice to a scalar attribute could log it as an orphan
[ticket:925]
- generative select.order_by(None) / group_by(None) was not managing to
reset order by/group by criterion, fixed [ticket:924]
exactly one expression in its columns clause.
- added "helper exception" to select.type access, generic functions raise
the chance of this happening
- a slight behavioral change to attributes is, del'ing an attribute
does *not* cause the lazyloader of that attribute to fire off again;
the "del" makes the effective value of the attribute "None". To
re-trigger the "loader" for an attribute, use
session.expire(instance, [attrname]).
- fix ormtutorial for IS NULL
the given argument; the previous behavior of constructing a list
of FROM clauses was generally not useful as is required
filter() calls to create join criterion, and new tables introduced
within filter() already add themselves to the FROM clause. The
new behavior allows not just joins from the main table, but select
statements as well. Filter criterion, order bys, eager load
clauses will be "aliased" against the given statement.
"unique identifier" mechanisms as everything else. This doesn't affect
user code, except any code that might have been hardcoded against the generated
names. Generated bind params now have the form "<paramname>_<num>",
whereas before only the second bind of the same name would have this form.
- bindparam() objects themselves can be used as keys for execute(), i.e.
statement.execute({bind1:'foo', bind2:'bar'})
- changed the various "literal" generation functions to use an anonymous
bind parameter. not much changes here except their labels now look
like ":param_1", ":param_2" instead of ":literal"
- from_obj keyword argument to select() can be a scalar or a list.
e.g. select([x* 5]) produces "SELECT x * 5 AS anon_1".
This allows the labelname to be present in the cursor.description
which can then be appropriately matched to result-column processing
rules. (we can't reliably use positional tracking for result-column
matches since text() expressions may represent multiple columns).
- operator overloading is now controlled by TypeEngine objects - the
one built-in operator overload so far is String types overloading
'+' to be the string concatenation operator.
User-defined types can also define their own operator overloading
by overriding the adapt_operator(self, op) method.
- untyped bind parameters on the right side of a binary expression
will be assigned the type of the left side of the operation, to better
enable the appropriate bind parameter processing to take effect
[ticket:819]
when its an alias of a Table; added some test coverage for one particular
case from the doctests
- fixed "having" example in doctests, updated eager load example
- removed ClauseParameters object; compiled.params returns a regular dictionary
now, as well as result.last_inserted_params()/last_updated_params().
- various code trimming, method removals.
~(x <operator> y) produces NOT (x <op> y), which is better compatible with MySQL.
[ticket:764]. this doesn't apply to "~(x==y)" as it does in 0.3 since ~(x==y)
compiles to "x != y", but still applies to operators like BETWEEN.
"column_keys". the parameters sent to execute() only interact with the
insert/update statement compilation process in terms of the column names
present but not the values for those columns.
produces more consistent execute/executemany behavior, simplifies things a
bit internally.
- all executemany() style calls put all sequences and SQL defaults inline into a single SQL statement
and don't do any pre-execution
- regular Insert and Update objects can have inline=True, forcing all executions to be inlined.
- no last_inserted_ids(), lastrow_has_defaults() available with inline execution
- calculation of pre/post execute pushed into compiler; DefaultExecutionContext greatly simplified
- fixed postgres reflection of primary key columns with no sequence/default generator, sets autoincrement=False
- fixed postgres executemany() behavior regarding sequences present, not present, passivedefaults, etc.
- all tests pass for sqlite, mysql, postgres; oracle tests pass as well as they did previously including all
insert/update/default functionality
- also omitted all modules and classes that aren't expicitly public
- omitted 'Smallinteger' (small i), but it's still in schema
- omitted NullType-related items from types.__all__
- patched up a few tests to use sql.table and sql.column, other related.
of convert_bind_param() and convert_result_value() to callable-returning
bind_processor() and result_processor() methods. if no callable is
returned, no pre/post processing function is called.
- hooks added throughout base/sql/defaults to optimize the calling
of bind param/result processors so that method call overhead is minimized.
special cases added for executemany() scenarios such that unneeded "last row id"
logic doesn't kick in, parameters aren't excessively traversed.
- new performance tests show a combined mass-insert/mass-select test as having 68%
fewer function calls than the same test run against 0.3.
- general performance improvement of result set iteration is around 10-20%.
that anything which is a column expression does not have a "c" or a
"columns" attribute. Also works for select().as_scalar(); _ScalarSelect
is a columnelement, so you can't say select().as_scalar().c.foo, which is
a pretty confusing mistake to make. in the case of _ScalarSelect made
an explicit raise if you try to access 'c'.
[ticket:620]
- calling <column>.in_() (i.e. with no arguments) will return
"CASE WHEN (<column> IS NULL) THEN NULL ELSE 0 END = 1)", so that
NULL or False is returned in all cases, rather than throwing an error
[ticket:545]
uses operator precedence to more intelligently apply parenthesis
to clauses, provides cleaner nesting of clauses (doesnt mutate
clauses placed in other clauses, i.e. no 'parens' flag)
- added 'modifier' keyword, works like func.<foo> except does not
add parenthesis. e.g. select([modifier.DISTINCT(...)]) etc.
Jason Kirtland