staging database needs to be setup and set for migrations about allready HOT 14 CLOSED

I'll take this if someone would assign it.

from allready.

I noticed while testing the beta8 upgrade that a few things aren't working when connected to a SQL Server database (instead of the In Memory Database). For example, the SampleData crashes with a "Cannot insert explicit value because IDENTITY_INSERT is OFF"

from allready.

@shawnwildermuth we can't assign issues to anyone that isn't part of the core commit team. Of the issues you commented on, just add a comment to say "I've got this", and that helps us track it.

If you are working on all three, just edit your comments :)

from allready.

Will do.

from allready.

I'm running into this when 'upgrading' to Azure.
The issue come in that we're trying to set the Id Property which i is an Identity.
A work around for this is surround the SaveChanges method with a SQL Statement that turns on and off identity_insert.

dbContext.Database.ExecuteSqlCommand("SET IDENTITY_INSERT [dbo].[Resource] ON");
dbContext.SaveChanges();
dbContext.Database.ExecuteSqlCommand("SET IDENTITY_INSERT [dbo].[Resource] OFF");

The other alternative is not to set the Value for Resource.Id

from allready.

The whole DB generation/migration stuff is a bit of a mess with some mixed metaphors (and sample data includes keys for example). I need to see how much of it will work with InMemory store (which may just complicate matters) before I rip it all out, but I'm definitely going to remove Schema attributes (e.g. [key] since we're already specifying them in the Context schema generation. I may need to rebuild the migrations afterwards, but hopefully that will be the last time (unless RC/RTM break them as they've been doing every build).

Any objections before I do a big change to simplify it all? (should only affect the internal database/context changes, no external changes are necessary (e.g. no entity shape changes are necessary at this point))?

from allready.

Please do simplify. I think everyone is using InMemory right now (including the staging site on Azure) so having to rebuild the migration shouldn't be an issue. Now is the time to clean it up IMO

from allready.

@dpaquette is the simplification allowing for Azure hosting easier?

from allready.

@shawnwildermuth sorry I don't understand the question. Let's chat in person if we happen to be in the same room today

from allready.

These changes were merged. Is this open on purpose?

from allready.

I think staging still runs off the in memory version.

from allready.

Are we staging directly in an AzureWebsite? If so, we'll need third connection string for that server. I'll need to work with whomever is deploying it to make sure that they're overriding the EnvironmentVariables with the Azure connection strings. We don't want this to use the 'in-memory db' IMO.

from allready.

@shawnwildermuth Staging and Production are two different websites and two different SQL DBs.

And yes, we want staging running of a server.

@tonysurma and I will be getting that setup tomorrow morning, and then this issue can be closed (as you say, all the code has been merged.)

from allready.

in the last two days between me, @shawnwildermuth, @dpaquette and I am sure others we got this solved

from allready.