Closed GoogleCodeExporter closed 8 years ago
This wouldn't be too difficult to accomplish.
The ideal way would be to create a SqlServer2005dialect class to map the
different
dbtypes to the column types.
The SqlServerTransformationProvider class however is tightly coupled to the
dialect.
So even though the TransformationProvider can be re-used with the two different
types of dialects, the dependency between the TransformationProvider and the
Dialect
need to be eliminated otherwise we would be duplicating code in another
TransformationProvider.
Thoughts?
Original comment by dko...@gmail.com
on 8 Jun 2008 at 3:47
We could avoid code duplication with simple inheritance I think. Just override
the constructor on a subclass of
the SqlServerTransformationProvider. This might be the simplest solution.
But if we could figure out another way to manage those dependencies, that would
probably be a good thing.
A full-blown DI framework for a project of this size is probably overkill
though. We're only ever using one
Dialect/TransformationProvider combo at a time.
A Major refactoring of this area would probably only be desirable to set us up
for supporting different version
of a lot of different providers - which could be nice.
Original comment by geoffl...@gmail.com
on 8 Jun 2008 at 5:08
sounds good. inheritance will do fine. if the inheritance heirarchy gets out of
hand
we can refactor towards composition. I don't see a complex heirarchy forming in
this
portion of code however.
If I have time I will add this functionality. I am on the verge of a major
product
release from my company so I may be unavailable for the next week or so.
Original comment by dko...@gmail.com
on 8 Jun 2008 at 9:53
Original comment by geoffl...@gmail.com
on 11 Jun 2008 at 2:59
SVN 88
Refactored the ProviderFactory a bit. Now it loads Dialects and asks Dialects
for a
TransformationProvider. Seems to work fairly well and is pretty flexible.
Reversed the relationship of TransformationProvider -> Dialect to Dialect ->
TransformationProvider. That should make the loading of minor version variations
easier to manage going forward.
Implemented the SqlServer2005Dialect to support the things above.
Original comment by geoffl...@gmail.com
on 12 Jun 2008 at 7:29
Original comment by geoffl...@gmail.com
on 12 Jun 2008 at 7:34
Original issue reported on code.google.com by
geoffl...@gmail.com
on 6 Jun 2008 at 3:00