column mapping when generating a LIMIT/OFFSET subquery,
allows columns to map properly to result sets even
if long-name truncation kicks in [ticket:941]
- Importing testenv has no side effects- explicit functions provide similar behavior to the old immediate behavior of testbase
- testing.db has the configured db
- Fixed up the perf/* scripts
2. compiler names changed to be less verbose, unused classes removed.
3. Methods on Dialect which return compilers, schema generators, identifier preparers
have changed to direct class references, typically on the Dialect class itself
or optionally as attributes on an individual Dialect instance if conditional behavior is needed.
This takes away the need for Dialect subclasses to know how to instantiate these
objects, and also reduces method overhead by one call for each one.
4. as a result of 3., some internal signatures have changed for things like compiler() (now statement_compiler()), preparer(), etc., mostly in that the dialect needs to be passed explicitly as the first argument (since they are just class references now). The compiler() method on Engine and Connection is now also named statement_compiler(), but as before does not take the dialect as an argument.
5. changed _process_row function on RowProxy to be a class reference, cuts out 50K method calls from insertspeed.py
deterministic names now, based on their ordering within the
full statement being compiled. this means the same statement
will produce the same string across application restarts and
allowing DB query plan caching to work better.
- cleanup to sql.ClauseParameters since it was just falling
apart, API made more explicit
- many unit test tweaks to adjust for bind params not being
"pre" truncated, changes to ClauseParameters
means their lengths are dialect-dependent. So on oracle a label
that gets truncated to 30 chars will go out to 63 characters
on postgres. Also, the true labelname is always attached as the
accessor on the parent Selectable so theres no need to be aware
of the genrerated label names [ticket:512].
- ResultProxy column targeting is greatly simplified, and relies
upon the ANSICompiler's column_labels map to translate the built-in
label on a _ColumnClause (which is now considered to be a unique
identifier of that column) to the label which was generated at compile
time.
- still need to put a baseline of ColumnClause targeting for
ResultProxy objects that originated from a textual query.
Mike Bayer