in result sets is now case sensitive by
default. SQLAlchemy for many years would
run a case-insensitive conversion on these values,
probably to alleviate early case sensitivity
issues with dialects like Oracle and
Firebird. These issues have been more cleanly
solved in more modern versions so the performance
hit of calling lower() on identifiers is removed.
The case insensitive comparisons can be re-enabled
by setting "case_insensitive=False" on
create_engine(). [ticket:2423]
.c. attribute of a select().apply_labels()
is now based on <tablename>_<colkey> instead
of <tablename>_<colname>, for those columns
that have a distinctly named .key.
[ticket:2397]
- resolved some serious speed hits I missed, we need to ensure
only deannotated columns are used in the local/remote collections and soforth
so that hash lookups against mapped columns don't dig into __eq__()
- fix some other parity mismatches regarding stuff from [ticket:2453],
including finding another case where _deep_annotate() was doing the wrong thing,
new tests.
- [feature] Major rewrite of relationship()
internals now allow join conditions which
include columns pointing to themselves
within composite foreign keys. A new
API for very specialized primaryjoin conditions
is added, allowing conditions based on
SQL functions, CAST, etc. to be handled
by placing the annotation functions
remote() and foreign() inline within the
expression when necessary. Previous recipes
using the semi-private _local_remote_pairs
approach can be upgraded to this new
approach. [ticket:1401]
requires that the updated table be present
in the FROM clause when an alias of that
table is also present in the FROM clause.
The updated table is now always present
in the FROM, when FROM is present
in the first place. Courtesy sayap.
[ticket:2468]
- [bug] Removed warning when Index is created
with no columns; while this might not be what
the user intended, it is a valid use case
as an Index could be a placeholder for just an
index of a certain name.
- mssql
- [feature] Added interim create_engine flag
supports_unicode_binds to PyODBC dialect,
to force whether or not the dialect
passes Python unicode literals to PyODBC
or not.
mechanics which could lead to incorrect
rendering of SELECT statements with aliases
and joins, particularly when using
column_property(). [ticket:2453]
column access on a row would raise
AttributeError with non-C version,
NoSuchColumnError with C version. Now
raises AttributeError in both cases.
[ticket:2398]
string format would not be applied to a
Numeric value returned as integer; this
affected primarily SQLite which does
not maintain numeric scale settings.
[ticket:2432]
condition with a "literal" in it would
raise an error on compile with certain
kinds of deeply nested expressions
which also needed to render the same
bound parameter name more than once.
[ticket:2425]
invokes common table expression support
from the Core (see below). [ticket:1859]
- [feature] Added support for SQL standard
common table expressions (CTE), allowing
SELECT objects as the CTE source (DML
not yet supported). This is invoked via
the cte() method on any select() construct.
[ticket:1859]
in the corresponding selectable to take into account clones
of the target column. fixes [ticket:2419]
- have _make_proxy() copy out the _is_clone_of attribute on the
new column so that even more corresponding_column() checks
work as expected for cloned elements.
- add a new test fixture so that mapped tests can be specified
using declarative.
- using new traversal that returns the product of both sides
of a binary, starting to work with (a+b) == (c+d) types of joins.
primaryjoins on functions working
- annotations working, including reversing local/remote when
doing backref
of a Column as a string identifier in a
result set row. The .key is currently
listed as an "alternate" name for a column,
and is superseded by the name of a column
which has that key value as its regular name.
For the next major release
of SQLAlchemy we may reverse this precedence
so that .key takes precedence, but this
is not decided on yet. [ticket:2392]
is applied to columns in SELECT statements
allows "truncated" labels, that is label names
that are generated in Python which exceed
the maximum identifier length (note this is
configurable via label_length on create_engine()),
to be properly referenced when rendered inside
of a subquery, as well as to be present
in a result set row using their original
in-Python names. [ticket:2396]
- apply pep8 to test_labels
when set to False on Table, the Table can be autoloaded
without existing columns being replaced. Allows
more flexible chains of Table construction/reflection
to be constructed, including that it helps with
combining Declarative with table reflection.
See the new example on the wiki. [ticket:2356]
- [bug] Improved the API for add_column() such that
if the same column is added to its own table,
an error is not raised and the constraints
don't get doubled up. Also helps with some
reflection/declarative patterns. [ticket:2356]
CompileException for all type/statement compilation
issues, instead of InvalidRequestError or ArgumentError.
The DDL for CREATE TABLE will re-raise
CompileExceptions to include table/column information
for the problematic column. [ticket:2361]
problematic backends like Oracle.i
- move the check generated in r85017c4310d2 up for both label name/name
comparisions, fixes additional mismatches which can occur
object named "<a>_<b>" which matched a column
labeled as "<tablename>_<colname>" could match
inappropriately when targeting in a result
set row. [ticket:2377]
- requires that we change the tuple format in RowProxy.
Makes an improvement to the cases tested against
an unpickled RowProxy as well though doesn't solve the
problem there entirely.
against ORM-level column could be treated as
a distinct entity when producing certain
kinds of joined-inh joins. [ticket:2316]
- [bug] related to [ticket:2316], made some
adjustments to the change from [ticket:2261]
regarding the "from" list on a select(). The
_froms collection is no longer memoized, as this
simplifies various use cases and removes the
need for a "warning" if a column is attached
to a table after it was already used in an
expression - the select() construct will now
always produce the correct expression.
There's probably no real-world
performance hit here; select() objects are
almost always made ad-hoc, and systems that
wish to optimize the re-use of a select()
would be using the "compiled_cache" feature.
A hit which would occur when calling select.bind
has been reduced, but the vast majority
of users shouldn't be using "bound metadata"
anyway :).
so that generative methods work a bit better
off of cloned (this is almost a non-use case though).
In particular this allows with_only_columns()
to behave more consistently. Added additional
documentation to with_only_columns() to clarify
expected behavior, which changed as a result
of [ticket:2261]. [ticket:2319]
- document the crap out of with_only_columns, include caveats about
the change, etc.
particular name was processed
during a create/drop sequence. This allows
a create/drop sequence to work without any
calls to "checkfirst", and also means with
"checkfirst" turned on it only needs to
check for the ENUM once. [ticket:2311]
- MetaData() accepts "schema" and "quote_schema"
arguments, which will be applied to the same-named
arguments of a Table
or Sequence which leaves these at their default
of ``None``.
- Sequence accepts "quote_schema" argument
- tometadata() for Table will use the "schema"
of the incoming MetaData for the new Table
if the schema argument is explicitly "None"
- Added CreateSchema and DropSchema DDL
constructs - these accept just the string
name of a schema and a "quote" flag.
- When using default "schema" with MetaData,
ForeignKey will also assume the "default" schema
when locating remote table. This allows the "schema"
argument on MetaData to be applied to any
set of Table objects that otherwise don't have
a "schema".
- a "has_schema" method has been implemented
on dialect, but only works on Postgresql so far.
Courtesy Manlio Perillo, [ticket:1679]
Mike Bayer