I have been using Entity Framework for quite a while so one thing that has thrown me quite a bit is that OrmLite doesn't appear to have migration features.
If I change a code first DTO what is the best way to reflect those changes in the database? Do I have to write out the raw SQL for modifying it? How do I record the migration so I can roll it back if there is an issue? How do I commit that to version control?
OrmLite doesn't contain any data migration solutions itself but you can read about different approaches taken in:
In addition to dropping and recreating table schemas, OrmLite also includes Modify Schema API's, e.g. for adding/removing individual columns. There are additional APIs in the OrmLiteSchemaModifyApi class:
Thanks, do you have any online example of how you organise your tests for modifying database as that is not really clear to me how to do it? The API functions seem the most familiar to me to work with but I am not sure on a good way to structure it. Also having some way to roll quickly roll back would be nice in case I make a mistake.
Also as a side note the OrmLite doc is really long. Is there any version that has an index menu to navigate?
There's nothing special about using unit tests which is just used as a harness for being able to run individual adhoc migration tasks. I don't have a public copy of for what we use on internal projects but TechStacks.Tests shows an example of the migration tasks I was running whilst developing the new https://techstacks.io, e.g. in MigrationTasks.cs.
But it's not an example I'd recommend following as it was developed against the single AWS RDS db instance directly. Normally there would be single flag to indicate which DB to run against and each test would be idempotent and allow multiple runs where it would check if the new column exists before adding it, etc.
I'd just use what you're comfortable with, this approach works for me since I'm productive with it as I can create and run migration tasks from the same IDE using shared code-base. You may want to adopt a more formal approach that is run by CI instead of from an IDE / command-line.
There's no other version of OrmLite doc (which is on the TODO list to break up), but there is an interactive OrmLite guide on Gistlyn which walks through some of the major features.
Thanks, it's not really an issue now as I am early in project but I have had first hand experience of migrations causing issues when multiple people working on same project which is why I like EF system so much. Dbup looks pretty good but being able to manage migrations from code is my preferred method.
I guess I could build the tests in a way that they check for a schema version number in the database and the test only executes if the schema number matches the number the test was written to migrate. I will miss the automatically generated up/down methods though.
Any plans to introduce something like this in the future?
migration table would just need to maintain the test that's ran to prevent it from running again.
Any future features are on UserVoice, e.g. you can vote for this feature request to prioritize it sooner and get notified on any updates. The comments also suggest using FluentMigrator as an alternative, which looks like another a nice option.