Michael Bayer wrote:
>
> 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 ?
Would be pretty useful. Would the mapping have to go deeper, and
control the resolution of (e.g.) String -> PGString across the board for
the dialect?
The reflection factories would probably want some *args and **kw to pass
along column/type metadata snarfed up in the first phase of reflection.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
