Defining SubSonic 3 ActiveRecord migrations

Question

I'm starting an ASP.NET MVC project using SubSonic 3 ActiveRecord. I added a table Users with a primary key ID and recompiled T4 files to generate User class.

I want to make sure that, as I go along with the development, I can regenerate/migrate the database at any point. It looks like I have to create tables and relationships in the database, regenerating ActiveRecord classes and doing migration as described in http://subsonicproject.com/docs/3.0_Migrations. The old 2.x way of defining migrations doesn't seem to be available any more.

Is there a way to drive development from the code rather than database, by changing model classes, and have the database migrated accordingly, without using SimpleRepository? I don't want to put generated code into source code repository, but if I don't, I lose database schema (unless I export and save it manually).

Answer 1

You can still use SubSonic 3 as a DAL and let SubSonic 2.2 generate the migrations for you. You just need sonic.exe and it's dependencies to execute the migration files.

To be more precise, I have folder Migrations in my DataLayer Project, that keeps all the migration Files but set the BuildAction to none. So I have Syntax Highlighting (but no error checking unless I set BuildAction back to compile) but the code does not mess my project.

You can keep them in an own project, of course. But I like it this way to have it under version control and be sure that my current DAL is matching my migration version.

In addition, I have named my config file migration.config (instead of app.config/web.config) and use this commandline to execute my migrations.

Command:           /path/to/sonic.exe  
Arguments:         migrate /config migration.config
Working Directory: $(SolutionDir)MyProject.Datalayer

Notice the /config switch to override the config file sonic.exe is looking for.

Answer 2

You could have a look at SimpleRepository:

http://subsonicproject.com/docs/Simple_Repo_5_Minute_Demo

Answer 3

The document you linked to does state:

"Bottom line: if you're a developer that is concerned about database design, migrations might not be for you"

I suspect that for the detail of design you want (and I would too), the migrations may not be suitable?