can now provide "bind expressions" and
"column expressions" which allow compile-time
injection of SQL expressions into statements
on a per-column or per-bind level. This is
to suit the use case of a type which needs
to augment bind- and result- behavior at the
SQL level, as opposed to in the Python level.
Allows for schemes like transparent encryption/
decryption, usage of Postgis functions, etc.
[ticket:1534]
- update postgis example fully.
- still need to repair the result map propagation
here to be transparent for cases like "labeled column".
- added READMEs to all examples in each __init__.py and added to sphinx documentation
- added versioning example
- removed vertical/vertical.py, the dictlikes are more straightforward
types to more intelligently determine float() vs. Decimal(),
[ticket:1567]
- since result processing is a hot issue of late, the DBAPI type
returned from cursor.description is certainly useful in cases like
these to determine an efficient result processor. There's likely
other result processors that can make use of it. But, backwards
incompat change to result_processor(). Happy major version number..
Explicit imports make it easier for users to understand the examples.
Additionally a lot of the examples were fixed to work with the changes in the
0.5.x code base. One small correction to the Case expression. Thanks a bunch
to Adam Lowry! Fixes#717.
class. It can be subclassed to provide user-defined
SQL functions in an imperative style, including
with pre-established behaviors. The postgis.py
example illustrates one usage of this.
column_property(), relation() etc. can define
new comparison methods on the Comparator, which will
become available via __getattr__() on the
InstrumentedAttribute. In the case of synonym()
or comparable_property(), attributes are resolved first
on the user-defined descriptor, then on the user-defined
comparator.
Mike Bayer