0

I started a new project C#, and I used the "enable-migrations" command in the package console window. This naturally added migrations to my project. I then set automatic migrations to true, so that as I call "update-database" it will create my tables for me with all keys and that.

The only problem is that I have multiple websites where want to do this, which all use the ASP.NET membership provider to login. Which through automatic code migrations create a bunch of account tables for me to use. But the tables are all called the same, so if I do this targeting the same database for different sites they will overwrite eachother. So the question I got is this: How can I specify a prefix for my tables created by the entity framework?

I've seen several ideas on how to do this while searching, but they didn't work for me (the necessary properties wasn't there for some reason and so on.)

Thank you

Xenoxsis

jrummell
  • 42,637
  • 17
  • 112
  • 171
Daniel Olsen
  • 1,020
  • 2
  • 15
  • 27
  • Even if the tables were named differently, I don't think migrations will work if you share the same database between multiple applications as EF only creates one `_MigrationHistory` table. – jrummell Mar 25 '13 at 13:41

2 Answers2

1

I'm not sure how do you plan to do just that - if I'm getting it right you'd want to keep one database (shared) in between number of web sites - yet, have each site has its own membership tables, named differently, with different prefixes, right?

First problem is that for each Db/table name change - you need a 'code to match' - i.e. code first entities and code, the 'migration table' in the Db - and tables are all in sync - so it could all work together as it should. In that sense, just changing script or table names in Db won't work. It has to be done at the level of attributes (as @Steven suggested) or fluent configuration.

Which in your case, it means that somehow you'd need to 'build' separate configurations for each site, deploy them separately (code) to each site - and build one mega Db that contains all the small variants of each merged together.

That's going to be tough to manage - but you could try (what I described above) - I have no idea if it'd work (as this requires lot of 'infrastructure' to try this one) - but maybe along these lines...

  • put Table attributes (or via fluent config)
  • Build code - 'vary' the Table names for each - and rebuild (ideally you might need to employ some tool, code-generator to do this automatically in a batch - i.e. you build, copy files externally, change names and repeat)
  • Build 'migrations' for each case (Table name) also - save migrations as files - and also do Update-Database -Script to save the actual scripts for each case (important).
  • Save each migration - or we can say a 'script' to represent.
  • Once done - you'd need to merge the migrations - scripts - into one big master script - i.e. remove the identical set of tables (leave just one of course) - and copy all different sets for membership tables.
  • Remove the migration table from the database - as that'd surely be out of sync and won't let you do anything (or there is also a flag in code I think to just ignore that, don't have it right now). For details see below in my other post.
  • Deploy one master Db - using script you created
  • Deploy the specific code - to each of the sites.
  • Pray it'd all work :)

There must be something smarter - but on the other hand, migrations are not made to work for such scenarios, so it's going to be hard if not impossible to pull this off.

Some general info that might help...

How to synchronize migrations with existing databases - geared toward production scenarios, maintaining Db-s and CF to match. It's not exactly what you need but has a detailed description, possible ways to resolve this which I wrote a while ago...

MVC3 and Code First Migrations - "model backing the 'blah' context has changed since the database was created"

To summarize...

What works for me is to use Update-Database -Script

That creates a script with a 'migration difference', which you can manually apply as an SQL script on the target server database (and you should get the right migration table rows inserted etc.).

If that still doesn't work - you can still do two things...(more inside)...

Community
  • 1
  • 1
NSGaga-mostly-inactive
  • 14,052
  • 3
  • 41
  • 51
  • Thank you for that very elaborate explanation :) I take your point. My problem was (and is) that many webhotels (unoeuro, one.com and the like) all use a single db for each websites. Which means if you're creating sites on subdomain level, you'll need prefixes to separate the tables in that single db. I think I'll switch over to using just entity framework (no automatic code migrations) for the website - Thanks again :) – Daniel Olsen Mar 26 '13 at 08:02
0

I don't know of anyway to make Entity Framework do this automatically across all entities. But you could force a table name, or schema using attributes or fluent API to get the desired effect. For example:

[Table("[put prefix here]_Users", Schema = "[put schema here]")]
public class User { 
    // ... 
}
Steven V
  • 16,357
  • 3
  • 63
  • 76