LinuxDoku / migratordotnet

Automatically exported from code.google.com/p/migratordotnet
0 stars 0 forks source link

Support SQL Server 2005 Specific Things #17

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
SQL Server 2005 recommends using varchar(MAX) and nvarchar(MAX) these days
instead of text and ntext. There might be some others as well.

Support SQL Server 2005 by creating a specific dialect for it so that
people can specify SqlServer (2000) and SqlServer2005 (2005 and greater).

Original issue reported on code.google.com by geoffl...@gmail.com on 6 Jun 2008 at 3:00

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago

Original comment by geoffl...@gmail.com on 11 Jun 2008 at 2:59

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago

Original comment by geoffl...@gmail.com on 12 Jun 2008 at 7:34