SQL-ized!
Hit a few very small snags along the way... but I can now dump data from my SQLite database to a new SQL Server database and change between the 2 seamlessly. I had to track a lot more data than I had wanted to and there is at least one piece which isn't 100% perfect.
So, first snag. I tried to use Fluent nHibernate with my existing mapping files... apparently there was something about the Service class it didn't like. I probably could have research and found out what I did wrong, but I had already written the Fluent mapping files so I switched to those. Worked fine with them. So apparently I'm doing something different and more correct in Fluent than I was in my original mappings, but for the most part the two are compatible it seems.
Next issue I hit was the record Id's. I was taking a file from one Database and then saving it anew into the other. So the Id from the original object was changed when saved into the new database. This made things a little fun when there was a record with an association. I had to keep a dictionary of the old and new Id's so that I could retrieve the correct one from the database in the dictionary when matching them back up. This is also why my Services are probably broken. I allowed for services to have a parent in the same table. Since there was no guarantee that I would have loaded the parent by the time I loaded the child... there is a good chance things will blow up on me later :) so I will need to circle back and fix that one later.
Also, hit an odd scenario. Regular old nHibernate works spectacularly with my enumerations with absolutely no additional configuration. For some reason, Fluent nHibernate complained. I just ended up cast them as ints in the mapping files and things seemed good, but I found this odd for Fluent, that there was an area where non-Fluent was more "flexible" seeming.
After that I hit another odd scenario that I suppose I must have looked at a thousand times and never noticed. Again, a scenario where the "underdog" is the victor. SQLite dates accept 01-01-0001 (which is the default/min value in .Net) whereas SQL has a more limited DateTime value. I knew SQL had this limitation, and for some reason I assumed SQLite did too, never noticed while looking through Veronica's data that this wasn't true. So a number of my old records needed some error correction thrown into the Repository classes.
And lastly, there was some annoying extra column on my Customer table. It gets created with my nHibernate mappings, but not with my Fluent ones. The column looks like an error, but under a certain condition the code was calling it. I changed the query instead of the mapping, but the code seems fine now.
So, next step is to make the converter correctly map the Service table. Then convert the old application to Fluent nHibernate running on SQL Server instead of SQLite (this should be trivial since all of the setup code is in just few files).
Once that is all done... a battery of testing to make sure that everything still works given the Fluent mappings and SQL Server as opposed to nHibernate mappings and SQLite and then I should be ready to go on making this into a .Net 4 application of some sort.
So, first snag. I tried to use Fluent nHibernate with my existing mapping files... apparently there was something about the Service class it didn't like. I probably could have research and found out what I did wrong, but I had already written the Fluent mapping files so I switched to those. Worked fine with them. So apparently I'm doing something different and more correct in Fluent than I was in my original mappings, but for the most part the two are compatible it seems.
Next issue I hit was the record Id's. I was taking a file from one Database and then saving it anew into the other. So the Id from the original object was changed when saved into the new database. This made things a little fun when there was a record with an association. I had to keep a dictionary of the old and new Id's so that I could retrieve the correct one from the database in the dictionary when matching them back up. This is also why my Services are probably broken. I allowed for services to have a parent in the same table. Since there was no guarantee that I would have loaded the parent by the time I loaded the child... there is a good chance things will blow up on me later :) so I will need to circle back and fix that one later.
Also, hit an odd scenario. Regular old nHibernate works spectacularly with my enumerations with absolutely no additional configuration. For some reason, Fluent nHibernate complained. I just ended up cast them as ints in the mapping files and things seemed good, but I found this odd for Fluent, that there was an area where non-Fluent was more "flexible" seeming.
After that I hit another odd scenario that I suppose I must have looked at a thousand times and never noticed. Again, a scenario where the "underdog" is the victor. SQLite dates accept 01-01-0001 (which is the default/min value in .Net) whereas SQL has a more limited DateTime value. I knew SQL had this limitation, and for some reason I assumed SQLite did too, never noticed while looking through Veronica's data that this wasn't true. So a number of my old records needed some error correction thrown into the Repository classes.
And lastly, there was some annoying extra column on my Customer table. It gets created with my nHibernate mappings, but not with my Fluent ones. The column looks like an error, but under a certain condition the code was calling it. I changed the query instead of the mapping, but the code seems fine now.
So, next step is to make the converter correctly map the Service table. Then convert the old application to Fluent nHibernate running on SQL Server instead of SQLite (this should be trivial since all of the setup code is in just few files).
Once that is all done... a battery of testing to make sure that everything still works given the Fluent mappings and SQL Server as opposed to nHibernate mappings and SQLite and then I should be ready to go on making this into a .Net 4 application of some sort.
Comments
Post a Comment