[sqlalchemy] Re: geoalchemy and reflected tables

2009-09-14 Thread Christoph Böhme

Michael,

Michael Bayer  schrieb:
> 
> 
> On Sep 13, 2009, at 7:01 AM, Christoph Böhme wrote:
> 
> >
> > Hi all,
> >
> > I wonder if it is possible to reflect tables in a Postgres/PostGIS
> > database with geoalchemy 0.1. The geoalchemy documentation only
> > mentions delarative model definitions and my attempt to simply  
> > import *
> > from geoalchemy and then reflect on the tables resulted in a warning
> > when sqlalchemy came across the geometry colunm:
> >
> > /usr/lib/python2.6/site-packages/sqlalchemy/engine/base.py:1265:
> > SAWarning: Did not recognize type 'geometry' of column 'coords'
> >
> > I had a look at the geoalchemy sources to see if I have to register
> > geoalchemy with sqlalchemy to make it aware of the new column
> > types but
> > I could not find anything.
> 
> currently, the only official "hook" we have to allow additional
> types into a reflected table is to do the regular reflection,
> specifying additional columns manually which you know to have
> particular types. this of course defeats the purpose of reflection to
> some degree.

thanks for the clarification. Since I need to set the comparator
factory for my geometry columns any way I will stick to the official
way and define the columns manually. That works fine now.

Cheers,
Christoph

> The "unofficial" way to do it is to stick the descriptor and type
> into the dialect's "ischema_names" dictionary.in 0.5 this
> dictionary is at :
> 
> from sqlalchemy.databases import postgres
> postgres.ischema_names['coords'] = Geometry
> 
> and 0.6:
> 
> from sqlalchemy.dialects.postgresql import base as pg
> pg.ischema_names['coords'] = Geometry
> 
> if the Geometry type has additional arguments, those don't get
> passed along in this method.
> 
> There was at some point some proposals to allow the "ischema_names"  
> dictionary to have an "official" route to customization but it
> hasn't moved along.  the complexity there is once we make it
> "official", now whatever that system does/does not do is carved in
> stone for awhile, so we wanted to consider it carefully.
> > 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---



[sqlalchemy] Re: geoalchemy and reflected tables

2009-09-13 Thread Michael Bayer


On Sep 13, 2009, at 7:01 AM, Christoph Böhme wrote:

>
> Hi all,
>
> I wonder if it is possible to reflect tables in a Postgres/PostGIS
> database with geoalchemy 0.1. The geoalchemy documentation only
> mentions delarative model definitions and my attempt to simply  
> import *
> from geoalchemy and then reflect on the tables resulted in a warning
> when sqlalchemy came across the geometry colunm:
>
> /usr/lib/python2.6/site-packages/sqlalchemy/engine/base.py:1265:
> SAWarning: Did not recognize type 'geometry' of column 'coords'
>
> I had a look at the geoalchemy sources to see if I have to register
> geoalchemy with sqlalchemy to make it aware of the new column types  
> but
> I could not find anything.

currently, the only official "hook" we have to allow additional types  
into a reflected table is to do the regular reflection, specifying  
additional columns manually which you know to have particular types.   
this of course defeats the purpose of reflection to some degree.

The "unofficial" way to do it is to stick the descriptor and type into  
the dialect's "ischema_names" dictionary.in 0.5 this dictionary is  
at :

from sqlalchemy.databases import postgres
postgres.ischema_names['coords'] = Geometry

and 0.6:

from sqlalchemy.dialects.postgresql import base as pg
pg.ischema_names['coords'] = Geometry

if the Geometry type has additional arguments, those don't get passed  
along in this method.

There was at some point some proposals to allow the "ischema_names"  
dictionary to have an "official" route to customization but it hasn't  
moved along.  the complexity there is once we make it "official", now  
whatever that system does/does not do is carved in stone for awhile,  
so we wanted to consider it carefully.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---