in conjunction with "schema" for the owning
Table would fail to locate result rows due
to the MSSQL dialect's "schema rendering"
logic's failure to take .key into account.
[ticket:2607]
result-row targeting. It should be possible
to use a select() statement with string
based columns in it, that is
select(['id', 'name']).select_from('mytable'),
and have this statement be targetable by
Column objects with those names; this is the
mechanism by which
query(MyClass).from_statement(some_statement)
works. At some point the specific case of
using select(['id']), which is equivalent to
select([literal_column('id')]), stopped working
here, so this has been re-instated and of
course tested. [ticket:2558]
"ambiguous column error" would fail to
function properly if the given index were
a Column object and not a string.
Note there are still some column-targeting
issues here which are fixed in 0.8.
[ticket:2553]
column access on a row would raise
AttributeError with non-C version,
NoSuchColumnError with C version. Now
raises AttributeError in both cases.
[ticket:2398]
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
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.
a RowProxy result row such that no exception
throw is generated internally;
NoSuchColumnError() also will generate its
message regardless of whether or not the column
construct can be coerced to a string.
[ticket:2178]. Also in 0.6.8.
classes, produces the _Over() construct which
in turn generates "window functions", i.e.
"<window function> OVER (PARTITION BY <partition by>,
ORDER BY <order by>)".
[ticket:1844]
call are now wrapped in sqlalchemy.exc.StatementError,
and the text of the SQL statement and repr() of params
is included. This makes it easier to identify statement
executions which fail before the DBAPI becomes
involved. [ticket:2015]
column, and the "autoincrement" feature of various dialects
as well as the "sqlite_autoincrement" flag will honor
the underlying database type as being Integer-based.
[ticket:2005]
- Result-row processors are applied to pre-executed SQL
defaults, as well as cursor.lastrowid, when determining
the contents of result.inserted_primary_key.
[ticket:2006]
- Bind parameters present in the "columns clause" of a select
are now auto-labeled like other "anonymous" clauses,
which among other things allows their "type" to be meaningful
when the row is fetched, as in result row processors.
- TypeDecorator is present in the "sqlalchemy" import space.
which has not yet been assigned a name, i.e. as in
declarative, is used in a context where it is
exported to the columns collection of an enclosing
select() construct, or if any construct involving
that column is compiled before its name is
assigned. [ticket:1862]
allowed cursor errors to be raised consistently broke
the result.lastrowid accessor. Test coverage has
been added for result.lastrowid. Note that lastrowid
is only supported by Pysqlite and some MySQL drivers,
so isn't super-useful in the general case.
- improved pool docs
- typos etc.
- ClauseElement.execute() and scalar() make no sense - these are depreacted.
The official home is Executable.
- alias() is not executable, allowing it is sloppy so this goes under
the deprecated umbrella
has already been exhausted, has been closed,
or is not a result-returning result now
raises ResourceClosedError, a subclass of
InvalidRequestError, in all cases, regardless
of backend. Previously, some DBAPIs would
raise ProgrammingError (i.e. pysqlite), others
would return None leading to downstream breakages
(i.e. MySQL-python).
- Connection, ResultProxy, as well as Session use
ResourceClosedError for all "this
connection/transaction/result is closed" types of
errors.
is passed through render_literal_value(), which may
implement escaping of backslashes. [ticket:1400]
- Postgresql render_literal_value() is overridden which escapes
backslashes, currently applies to the ESCAPE clause
of LIKE and similar expressions.
Ultimately this will have to detect the value of
"standard_conforming_strings" for full behavior.
[ticket:1400]
- MySQL render_literal_value() is overridden which escapes
backslashes, currently applies to the ESCAPE clause
of LIKE and similar expressions. This behavior
is derived from detecting the value of
NO_BACKSLASH_ESCAPES. [ticket:1400]
- generalized the "freetds" / "unicode statements" behavior of MS-SQL/pyodbc
into the base Pyodbc connector, as this seems to apply to Sybase as well.
- generalized the python-sybase "use autocommit for DDL" into the pyodbc
connector. With pyodbc, the "autocommit" flag on connection is used,
as Pyodbc seems to have more database conversation than python-sybase that
can't otherwise be suppressed.
- Some platforms will now interpret certain literal values
as non-bind parameters, rendered literally into the SQL
statement. This to support strict SQL-92 rules that are
enforced by some platforms including MS-SQL and Sybase.
In this model, bind parameters aren't allowed in the
columns clause of a SELECT, nor are certain ambiguous
expressions like "?=?". When this mode is enabled, the base
compiler will render the binds as inline literals, but only across
strings and numeric values. Other types such as dates
will raise an error, unless the dialect subclass defines
a literal rendering function for those. The bind parameter
must have an embedded literal value already or an error
is raised (i.e. won't work with straight bindparam('x')).
Dialects can also expand upon the areas where binds are not
accepted, such as within argument lists of functions
(which don't work on MS-SQL when native SQL binding is used).
changes to Enum/SchemaType to re-support adaptation of string types.
This approach can be adapted by "conditional" unicode returning dialects
(i.e. pyodbc and possibly mxodbc) to remove the overhead
of isinstance(value, unicode) calls when the dialect returned type is
of dbapi.UNICODE, dbapi.NVARCHAR, etc.
Mike Bayer