I suggest you ...

OrmLite CodeFirst Schema Migrations

Support to automatically update a db schema based on changes such as: adding/renaming and possibly removing a property or class.

98 votes
Sign in
Sign in with: facebook google
Signed in as (Sign out)
You have left! (?) (thinking…)
Ty shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Sign in with: facebook google
Signed in as (Sign out)
  • Andriy commented  ·   ·  Flag as inappropriate

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

  • Andriy commented  ·   ·  Flag as inappropriate

    Hello Guys,

    Do you plan to implement this?

    I saw in your API already there is methods to do this like:

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


  • Marco commented  ·   ·  Flag as inappropriate

    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..

  • AdminDemis J Bellot (Developer, ServiceStack) commented  ·   ·  Flag as inappropriate

    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.

  • Johann Klemmack commented  ·   ·  Flag as inappropriate

    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?

  • Ty commented  ·   ·  Flag as inappropriate

    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)

Feedback and Knowledge Base