Hi guys!

This isn't actually a feature request, but more of a product idea. I'd gladly pay around half what I'm paying for ES' license for something like this. Heck, I'd even code it myself and sell it if I didn't need to go through the whole "writing database-specific backend" part (which you already have solved).

In my current project I'm using "Migrations". I think the terminology comes originally from the Ruby On Rails project, but basically it's a way to write code that generates the database structure for your project. As the name suggests, you can later add and remove tables/fields/foreign keys from the database just by adding new "migrations" to your project. It's clearly a winner when you are using a versioning system, because you can not only keep your code, but your database structure versioned without having to make SQL snapshots.

There are a few .NET frameworks to do that, but all of them are in their early infancy. The most robust/mature I found was Migrator.NET (available at h-t-t-p://code.google.com/p/migratordotnet/), and that is what I'm using. But even if it has proper multi-database support, it doesn't have a simple way to create views for example, and so you have to go and write database-specific code for each view you want to create. That could be solved if the developer had something nice like ES' DynamicQueries. Also, it doesn't support fixtures (i.e. data you can inject in the database as soon as the migration is done), so you have to re-import the pertinent data by hand every time you migrate.

I'm really looking forward to set my eager bear-paws (yeah, my hands are *that* big) on something like 'EntityMigrations' :)

Cheers,

David

I took a look at this tonight, it's a pretty cool idea, here is one of their classes:

using Migrator.Framework;
using System.Data;

[Migration(3)]
public class AddPersonTable : Migration
{
    override public void Up()
    {
        Database.AddTable("Person", 
            new Column("id", DbType.Int32, ColumnProperty.PrimaryKey),
            new Column("first_name", DbType.String, 50),
            new Column("last_name", DbType.String, 50),
            new Column("address_id", DbType.Int32, ColumnProperty.Unsigned)
        );
        Database.AddForeignKey("FK_PERSON_ADDRESS", "Person", "address_id", "Address", "id");
    }
    override public void Down()
    {
        Database.RemoveTable("Person");
    }
}

My thoughts are first it's too bad we have to inherit from their base classes ( I know ES makes you do the same thing) and I wish it was just that we had to implement an interface, such as IMigration or something and we could probably add this as an options, or, in ES2009 you could make this a template snippet. Either way, generating something like this is trivial using our EntitySpaces.MetadataEngine.dll and our templates. Let me look at this some more. So are you still using it and are you hand typing all that in?

Hi!

Yes, I'm still using Migrator.NET and yes, I'm still typing all that in :). They distribute a tool that supposedly generates the code from a database, but it's quite rough. Actually, in my trials, I only got it to generate C# code that mapped all database fields to strings, and completely ignored the relations between tables and foreign keys, constraints, etc.

I guess the best possible thing would be extending Migrator.NET (or any of the projects) to include syntax to generate views in a database-independent manner, and then create templates to generate the "initial migration" from an existing database. So the workflow would go like:

1. Design your database using your favourite tool, on your favourite database server.
2. Create a MyGeneration project that includes both ES templates and the Initial Migration template.
3. Add the generated files to your project.
4. If later you need to modify the database design:
1. Add a new migration in your project.
2. Run the migration.
3. Re-run ES Generated Classes template.

Voila! Now you can modify your database as you wish, and access it without caring what kind of server is on the other end. All in your code, no need to keep tabs on database changes, etc. You can even tell your clients to use whatever server they want (as long as it is supported by the migration framework), and you only need to run a single command to build the database on that server.

Does that make sense?