On Aug 6, 4:09 pm, Sanjiv Singh <singhsanj...@gmail.com> wrote:
> > Also the GeometryDDL and Geometry classes could use some refactoring
> > to support extensibility of adding new dialects. Probably via a
> > registry that maps dialects to their geometry implementations. Also,
> > the GeometryDDL doesn't account for the fact that dialects could be
> > subclassed.
>
> I am not sure I totally understand the solution you are suggesting.
> Could you elaborate a bit more? Is there some code I could look at
> that does something similar?
Regular refactoring of if's to a class hierarchy. Create a base
strategy class that defines the template methods for before-create,
after-create etc. and then put the DB specific implementations into db
specific subclasses that can live in the db specific modules.
(geoalchemy.postgis.PGGeometyDDL etc.) To create the objects use a
dict to map dialects to GeometryDDL implementations:
ddl_registry = {
('sqlalchemy.databases.postgres', 'PGDialect'): PGGeometryDDL,
...
}
def dialect_to_ddl_impl(dialect):
for cls in type(dialect).__mro__:
cls_id = cls.__module__, cls.__name__
if cls_id in ddl_registry:
return ddl_registry[cls_id]()
else:
raise NotImplementedError
This allows other implementers to add their class to the ddl_registry
and support other databases without changing your code. You could even
use setuptools entry points to handle the registering part. Something
like this is in sqlalchemy.engine.url.URL.get_dialect.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
