Chris Cranford, in my opinion, integrating the logic of the spatial dialects into the parent (non spatial) classes would be the "cleaner" solution. SQL Server 2008 supports spatial features, so there is no reason to make a difference between the SQLServer2008Dialect and the SqlServer2008SpatialDialect.

I have taken a look at the implementations of SqlServer2008SpatialDialect and OracleSpatial10gDialect. Integrating the logic of these classes into the parent classes would be very easy (and not much effort):

• The parent classes need to implement the SpatialDialect interface
• The methods of SqlServer2008SpatialDialect and OracleSpatial10gDialect which implement the SpatialDialect interface can be moved to the parent classes
• The remaining code (from constructor and from the contributeTypes method) can also be moved to the parent classes

That is all. The SqlServer2008SpatialDialect and OracleSpatial10gDialect are empty now and may be dropped (or kept for compatibility reasons).

The advantage of this aproach is that after this change, the SQLServer2012Dialect and Oracle12cDialect classes would implement the SpatialDialect interface automatically (as they extend from SQLServer2008Dialect and Oracle10gDialect).

I guess, the migration of the other spatial dialect classes would be as easy as described for the SqlServer2008SpatialDialect and OracleSpatial10gDialect classes.