are to work around glitchy SQLite behavior that doesnt understand
"foo.id" as equivalent to "id", are now only generated in the case
that those named columns are selected from (part of [ticket:513])
- MS-SQL better detects when a query is a subquery and knows not to
generate ORDER BY phrases for those [ticket:513]
- much more functionality moved into ExecutionContext, which impacted
the API used by dialects to some degree
- ResultProxy and subclasses now designed sanely
- merged patch for #522, Unicode subclasses String directly,
MSNVarchar implements for MS-SQL, removed MSUnicode.
- String moves its "VARCHAR"/"TEXT" switchy thing into
"get_search_list()" function, which VARCHAR and CHAR can override
to not return TEXT in any case (didnt do the latter yet)
- implements server side cursors for postgres, unit tests, #514
- includes overhaul of dbapi import strategy #480, all dbapi
importing happens in dialect method "dbapi()", is only called
inside of create_engine() for default and threadlocal strategies.
Dialect subclasses have a datamember "dbapi" referencing the loaded
module which may be None.
- added "mock" engine strategy, doesnt require DBAPI module and
gives you a "Connecition" which just sends all executes to a callable.
can be used to create string output of create_all()/drop_all().
Fix to null FLOAT fields in mssql-trusted.patch
MSSQL: LIMIT with OFFSET now raises an error
MSSQL: can now specify Windows authorization
MSSQL: ignores seconds on DATE columns (DATE fix, part 1)
- documented instance variables in ANSICompiler
- fixed [ticket:120], adds "inline_params" set to ANSICompiler which DefaultDialect picks up on when
determining defaults. added unittests to query.py
- additionally fixed up the behavior of the "values" parameter on _Insert/_Update
- more cleanup to sql/Select - more succinct organization of FROM clauses, removed silly _process_from_dict
methods and JoinMarker object
behavior should be the same, except now you can also do things like
select(['*'], from_obj=[func.my_function()]) to get multiple
columns from the result, or even use sql.column() constructs to name the
return columns [ticket:172]. generally only postgres understands the
syntax (and possibly oracle).
Mike Bayer