I think you could have a method like Db.UpdateTableSchema<Entity>() which would compare columns and add/remove/iniialise accordingly. Then it would be quicker modifying tables. I am using DbUp atm and it is annoying having to write a SQL script every time I change an entity model. On non-critical tables that might change I could just call this method in startup and it would keep everything in sync mainly and save time.

You can use https://github.com/ServiceStack/Issues for submitting reproducible issues with our current libraries or the Customer Forums (https://forums.servicestack.net) for any other technical discussions

It will be good if you open issues on github

I think need to have db.GetColumns<T>():List<FieldDefinition> which populate fields description from DB to move forward with automigrations.

Hello Guys,

Do you plan to implement this?

I saw in your API already there is methods to do this like:
db.AlterColumn
db.AlterTable
db.AddColumn

Just need to implement diff between Domain Modes and schema DB.
If you need some help - I can help.

Thanks.

If one sticks with FluentMigrator - then there is some other ongoing work to generate the migrations from the code - but still let the programmer adjust it, ref https://github.com/schambers/fluentmigrator/issues/476

Another alternative would be to add some helper migration classes with a backend version table and a simple Up / Down class/interface ..
Most projects need this..

Whilst it's a nice idea I don't trust really tools that try to migrate based on schema of existing types (it's also tough to have different versions of the same type in the same project) - IMO it's too fragile and lacks visibility/control. My preferred approach is to just to run explicit custom DDL statements to migrate from a previous version, that way I'm always in control of what operations are applied to the RDBMS.

We had a pretty good solution for this whilst I was at StackOverflow, I hope to introduce something similar at some stage - but atm I'm just running migrations manually using a Migration Tasks Tests which I can configure to run against different RDBMS's just before deploying when a migration is required.

I've been poking some at this for my own use. The "easiest" approach is if there are two schemas (before & after) and you could migrate between them. However, that defeats some of the benefits of ServiceStack (resilient DTOs, sharing DTO with DB schema). The other approach is to infer the ModelDef from the database, but that could get gnarly quickly. Preference on approach?

EF also have some initializers which would be great. They have a Seed method which can be called if db does not exist or if schema version if different, which is a great place for data migrations (or at least where i do it)