new features in SQLAlchemy 0.8 + new postgis reference example
384 views
Skip to first unread message
Michael Bayer
Aug 18, 2012, 3:34:10 PM8/18/12
to GeoAlchemy
Hello Geoalchemers -
Have already been talking to Eric about this, I've added a new set of
features for SQLAlchemy 0.8 that I'm hoping will enable libraries like
Geoalchemy to work a lot better and no longer require any ORM
dependencies.
The two features that have been added are as follows:
1. the ability to associate custom operators with types.
Historically, the only real path to associate new operators with
columns would be to pass in a Comparator class to the
comparator_factory argument of column_property(); this is the
SpatialComparator I see in GA's source code at the moment.
The same idea has been ported to the Core, where any column expression
at all will consult its type for available operators - so the
SpatialComparator series of operations can now be local to the
GeometryBase type. The epic win here is that *any* SQL expression of
any kind that is of the GeometryBase type gets all those operations.
There is already a well defined set of behaviors in place that
propagate the type on a source column into expressions derived from
it. Any SQL expression that isn't of GeometryBase can be "cast" to
it using the type_coerce() function, which is a little known function
in the Core.
docs for this are at: http://docs.sqlalchemy.org/en/latest/core/types.html#redefining-and-creating-new-operators
2. the ability to associate SQL functions and other "wrapping"
expressions with types. The GeometryBase type has bind_processor()
and result_processor() methods which allow application of Python
transformations to data as it is sent to the database and as it is
returned to the app. Two new methods, bind_expression() and
column_expression() do the same thing, except they affect the
rendering of the SQL statement directly. This is where you can have
data going between the database and the app, being translated by
ST_GeomFromText and ST_AsText symmetrically.
docs for this are at: http://docs.sqlalchemy.org/en/latest/core/types.html#applying-sql-level-bind-result-processing
The current demo in terms of Postgis can be viewed here:
https://bitbucket.org/sqlalchemy/sqlalchemy/src/f3425add3d2d/examples/postgis/postgis.py
. Of note are that there's no ORM dependencies at all, and the DDL
area has been streamlined a bit.
In terms of GeoAlchemy, I'm hoping this can introduce a smaller,
simpler GeoAlchemy with much improved consistency of behavior. If it
were me, I'd call it GeoAlchemy 2 and do a clean break from any
pre-0.8 dependencies. SQLAlchemy releases a new "major version"
each year and the userbase for the most part keeps up, so once 0.8
gets underway the GeoAlchemy project would do fine to go forward
developing against just this version forward.
As far as 2.0, SQLAlchemy is very interested in finally going "1.0",
and I am considering ways to spend only a brief period within "0.8",
possibly bumping right to 1.0 at some point.
Have already been talking to Eric about this, I've added a new set of
features for SQLAlchemy 0.8 that I'm hoping will enable libraries like
Geoalchemy to work a lot better and no longer require any ORM
dependencies.
The two features that have been added are as follows:
1. the ability to associate custom operators with types.
Historically, the only real path to associate new operators with
columns would be to pass in a Comparator class to the
comparator_factory argument of column_property(); this is the
SpatialComparator I see in GA's source code at the moment.
The same idea has been ported to the Core, where any column expression
at all will consult its type for available operators - so the
SpatialComparator series of operations can now be local to the
GeometryBase type. The epic win here is that *any* SQL expression of
any kind that is of the GeometryBase type gets all those operations.
There is already a well defined set of behaviors in place that
propagate the type on a source column into expressions derived from
it. Any SQL expression that isn't of GeometryBase can be "cast" to
it using the type_coerce() function, which is a little known function
in the Core.
docs for this are at: http://docs.sqlalchemy.org/en/latest/core/types.html#redefining-and-creating-new-operators
2. the ability to associate SQL functions and other "wrapping"
expressions with types. The GeometryBase type has bind_processor()
and result_processor() methods which allow application of Python
transformations to data as it is sent to the database and as it is
returned to the app. Two new methods, bind_expression() and
column_expression() do the same thing, except they affect the
rendering of the SQL statement directly. This is where you can have
data going between the database and the app, being translated by
ST_GeomFromText and ST_AsText symmetrically.
docs for this are at: http://docs.sqlalchemy.org/en/latest/core/types.html#applying-sql-level-bind-result-processing
The current demo in terms of Postgis can be viewed here:
https://bitbucket.org/sqlalchemy/sqlalchemy/src/f3425add3d2d/examples/postgis/postgis.py
. Of note are that there's no ORM dependencies at all, and the DDL
area has been streamlined a bit.
In terms of GeoAlchemy, I'm hoping this can introduce a smaller,
simpler GeoAlchemy with much improved consistency of behavior. If it
were me, I'd call it GeoAlchemy 2 and do a clean break from any
pre-0.8 dependencies. SQLAlchemy releases a new "major version"
each year and the userbase for the most part keeps up, so once 0.8
gets underway the GeoAlchemy project would do fine to go forward
developing against just this version forward.
As far as 2.0, SQLAlchemy is very interested in finally going "1.0",
and I am considering ways to spend only a brief period within "0.8",
possibly bumping right to 1.0 at some point.
Eric Lemoine
Aug 19, 2012, 4:18:29 PM8/19/12
to geoal...@googlegroups.com
Thanks Mike!
Yes, GeoAlchemy 2 based on SQLAlchemy 0.8 (and 1.0 later) would make sense. There are areas where the GeoAlchemy API leaves much to be desired. GeoAlchemy 2 would be a good opportunity to fix that as well.
--
Eric Lemoine
Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex
Tel : 00 33 4 79 44 44 96
Mail : eric.l...@camptocamp.com
http://www.camptocamp.com
Reply all
Reply to author
Forward
0 new messages