On Jul 13, 2008, at 5:42 PM, Eric Lemoine wrote:
>
> So far, so good; user can do:
>
> wifi_table = Table('wifi', metadata,
> Column('the_geom', Geometry(4326)),
> autoload=True)
>
> But ultimately I'd like that my users can do:
>
> wifi_table = Table('wifi', metadata, autoload=True)
>
> I tried this:
>
> from sqlalchemy.databases import postgres
> postgres.ischema_names['geometry'] = Geometry
>
> This is ok, but during reflection, when SQLA creates Geometry objects,
> it obviously passes no "srid" argument to the Geometry constructor, so
> the Geometry objects all end up with the "srid" property set to -1.
> The proper "srid" value to pass to the Geometry constructor is
> actually in a PostGIS table (geometry_columns). So if a geometry
> column is discovered, the table's "srid" value could be read from that
> table and passed to the Geometry constructor. I thought about doing
> something like that:
>
> from sqlalchemy.databases import postgres
> def geometry_factory():
> // go read srid associated with table from geometry_columns
> srid =
> return Geometry(srid)
> postgres.ischema_names['geometry'] = geometry_factory
>
> but geometry_factory doesn't have any connection object to go read the
> srid value.
>
> My question is simple: do you see solutions to my problem?
like before with asdecimal=False, we dont have a standard API for the
"ischema_names" dict and again here is a place where you're looking
for one. Such an API might look like:
def create_postgis_type(table, connection):
srid = connection.execute("select whatever you need to figure
out
SRID value").scalar()
return Geometry(srid=srid)
engine = create_engine('postgres://...', type_reflectors={
'numeric':PGFloat,
'PostGIS':create_postgis_type
})
where reflecttable() distinguishes between a TypeEngine class and a
plain callable, which is assumed to implement a particular API. But
thats just a guess. I wouldn't implement such an API casually since
while its very easy to add little features like this, its much harder
to change them or take them away after you've observed they're a bad
idea or were not well thought out (additionally this one's a pretty
big job to implement across every dialect). Any opinions from Jason/
Rick/other ?
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---
