Somehow either, my C# code, or entity framework 6 is dropping and creating a database when I run
PM> update-database -verbose
from an explicit migration with an up() method that looks like this...
public override void Up()
{
AddColumn("dbo.Term", "Term_Id", c => c.Int());
CreateIndex("dbo.Term", "Term_Id");
AddForeignKey("dbo.Term", "Term_Id", "dbo.Term", "Id");
}
-verbose generates this...
Origin: Configuration).
Applying explicit migrations: [201410271927053_addTermsTable2].
Applying explicit migration: 201410271927053_addTermsTable2.
ALTER TABLE [dbo].[Term] ADD [Term_Id] [int]
CREATE INDEX [IX_Term_Id] ON [dbo].[Term]([Term_Id])
ALTER TABLE [dbo].[Term] ADD CONSTRAINT [FK_dbo.Term_dbo.Term_Term_Id] FOREIGN KEY ([Term_Id]) REFERENCES [dbo].[Term] ([Id])
INSERT [dbo].[__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion])
(plus the migration insert statement)
None of which indicates (to me) the db is about to be dropped.
Can someone confirm this does not drop?
Does it matter that
this is an Azure SQL database?
that the columns were added in response to adding this.. to the class?
public virtual ICollection<Term> urls { get; set; }
Any pointers on how to make sure I know when a drop create is going to occur?
Thanks.
Related
I have recently been using PostgreSQL rather than SQL, so finding a lot of little nuances between the two.
I want to be able to make a string value unique in a table, so using the EF code first fluent API, I have this code.
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<MyTable>()
.HasIndex(u => u.UniqueValue)
.IsUnique();
base.OnModelCreating(modelBuilder);
}
When creating a migration, it will generate this.
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.CreateIndex(
name: "IX_MyTable_UniqueValue",
table: "MyTable",
column: "UniqueValue",
unique: true);
}
This will then add the index to the PostgreSQL table, and work when the word is of the same case.
e.g. Try and insert "Hello" twice, and it will not work.
It does allow for variations of the word though, so I can insert "Hello", "HEllo", "HELlo", etc...
It looks like it is possible to force the case on the index in PostgreSQL using something like
CREATE UNIQUE INDEX UniqueValue ON MyTable (UPPER(UniqueValue));
However I am not sure how to do this via EF Fluent API and create the migration from that?
It seems like for now you'll have to set up a raw SQL migration. Support for that still hasn't been added (yet). You could also set up a generated (computed) column that holds the result of upper(UniqueValue), then add a unique index on that.
There's no way to add an expression-based unique constraint or to add the expression to an existing unique index key. You can build a new index using your definition as is:
CREATE UNIQUE INDEX UniqueValue ON MyTable (UPPER(UniqueValue));
Or add an exclusion constraint which ends up doing pretty much the same (as of now, quite far from being supported in EF):
create table test(txt text);
alter table test
add constraint case_insensitive_unique
exclude using gist(upper(txt) with =);
insert into test(txt) select 'hello';
--INSERT 0 1
insert into test(txt) select 'Hello';
--ERROR: conflicting key value violates exclusion constraint "case_insensitive_unique"
--DETAIL: Key (upper(txt))=(HELLO) conflicts with existing key (upper(txt))=(HELLO).
Demo
We've started using EF6 as part of rewriting our application suite. There are many perfectly reasonable tables in the existing suite and we're reusing them using a database-first approach. My problem is that EF6 seems to be enforcing what I think are code-first conventions on my database-first model.
Consider this minimal example with two tables defined thusly and appropriately populated with a few rows:
CREATE TABLE [dbo].[Table1] (
[Id] INT NOT NULL PRIMARY KEY,
[Table2Reference] INT NOT NULL REFERENCES [dbo].[Table2](Id) )
CREATE TABLE [dbo].[Table2] (
[Id] INT NOT NULL PRIMARY KEY,
[SomeColumn] NVARCHAR(25) )
After running Update Model From Database we get this model:
(Oops. Not enough reputation to post images. It's what you would imagine.)
So far so good, but when you write code to access the Table1 entity, like so...
var q = _context.Table1.ToList();
foreach (var item in q)
Debug.WriteLine("{0}", item.Table2Reference);
... it compiles fine but will throw on the ToList() line. This is because the SQL generated contains a request for a column that doesn't even exist:
SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Table2Reference] AS [Table2Reference],
[Extent1].[Table2_Id] AS [Table2_Id] <-- this one doesn't exist
FROM [dbo].[Table1] AS [Extent1]
I gather this has something to do with a code-first naming convention for foreign keys. I know I can rename Table2's Id column to Table2Id and rename Table2Reference to Table2Id and it will work. However, this is supposed to be database-first. Is there some way to tell EF to get out of the way and just go with what is actually in the pre-defined database? I did discover early on that I had to turn off the name pluralizing convention, but I can't seem to identify a convention to turn off that fixes this problem. I tried removing these:
modelBuilder.Conventions.Remove<PrimaryKeyNameForeignKeyDiscoveryConvention>();
modelBuilder.Conventions.Remove<TypeNameForeignKeyDiscoveryConvention>();
modelBuilder.Conventions.Remove<NavigationPropertyNameForeignKeyDiscoveryConvention>();
Anyway, I'm stumped. Is there an easy workaround that doesn't involve modifying the existing database?
Thanks for reading.
You can use data annotations attributes or fluent API to configure EF mapping to actual database tables. Here is how it can be done with attributes:
[Table("Table1")]
public class Table1
{
public int Id { get; set; }
public int Table2Reference { get; set; }
[ForeignKey("Table2Reference")]
public Table2 Table2 { get; set; }
}
It turns out that there is a very important piece to a database-first approach besides having an EDMX file. That is, your connection string must contain the following section:
metadata=res:///IPE.csdl|res:///IPE.ssdl|res://*/IPE.msl; (replacing IPE with the base name of your EDMX)
Otherwise, EF will be unable to locate the EDMX information in the assembly and code-first conventions can come into play. Mostly things just work, until they don't.
EF6 is pluralizing my Code First table names no matter what I do. I am getting the error that it can't find the pluralized table {"Invalid object name 'dbo.TestStats'."}. The table is singular in the DB as dbo.TestStat
I tried removing the convention by
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
I have also mapped it to the singular table name
public TestStatMap()
{
// Primary Key
this.HasKey(t => t.TestStatId);
this.ToTable("TestStat");
I have even tried adding this to the OnModelCreating override
modelBuilder.Entity<TestStat>().ToTable("TestStat");
Here is the table that I am trying to map it to, which was generated by the EF power tools. What else can I try or what am I missing?
CREATE TABLE [dbo].[TestStat] (
[TestStatId] [int] NOT NULL IDENTITY,
[SeasonID] [int],
[TeamID] [int],
CONSTRAINT [PK_dbo.TestStat] PRIMARY KEY ([TestStatId])
)
Figured out my own mistake. I have two Context classes, one inheriting from the other for the repository, and I had the code below in the base context, when I moved it to the derived it now works. modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
if using .net 4.5 remove this line from app.config/web.config
<startup><supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /></startup>
I try to change MaxLength property from 100 to 50 and i got exception that Says
"The index 'IX_Singers_Name' is dependent on column 'Name'.
ALTER TABLE ALTER COLUMN Name failed because one or more objects access this column."
Mode is :
public class Singer : NamedEntity
{
[MaxLength(50)] // It was 100
public override string Name { get; set; }
}
As i understand, entity framework needs to alter table for this change but it can't alter table because an index exist on Name property. So how i can make it possible with entity framework migrations ?
I can possibly drop index in migration then change maxlength in next migration and create index the last migration again. But i believe that there should be exist an easy way to change that attribute value.
In SQL Server, indexes are pretty much like tables themselves. So if you've got the column in an index, both that index and the table would need to be modified. I agree that where EF migrations were scaffolded to add the index (e.g. for a foreign key) they should also take care of removing and reapplying the index. However, in this instance the index would have had to have been added manually. Therefore it will need to be maintained manually in the migration. Note that it can be done in a single migration:
public override void Up()
{
DropIndex("dbo.Singer", new []{"Name"});
/* Code to alter the table */
CreateIndex("dbo.Singer", "Name");
}
Don't forget to put this in both the Up() and Down() methods.
Using Entity Framework 4.3.1 CodeFirst and having no luck getting the migrations or scripts to respect the schema that I want my tables to end up in.
It seems the default behavior (the one that I'm seeing regardless of what I do) is to omit the schema completely from the SQL that actually runs causes tables to be created in the default schema for the user running the migration or script.
My DBAs are telling me that they cannot change my default schema due to the fact that I'm part of an AD group and not a local user, so changing the default schema for the user running (an often recommended workaround) the script is not an option at all.
I've tried using the annotations like this:
[Table("MyTable", Schema = "dbo")]
public class MyTable
{
public int Id { get; set; }
public string MyProp1 { get; set; }
public string MyProp2 { get; set; }
}
And I've also tried using the fluent variant of the same thing:
modelBuilder.Entity<YourType>().ToTable("MyTable", "dbo");
The resultant script (and migrations) ignore the fact that I tried to specify a schema. The script looks like this:
CREATE TABLE [MyTable] (
[Id] [int] NOT NULL IDENTITY,
[MyProp1] [nvarchar](max),
[MyProp2] [nvarchar](max),
CONSTRAINT [PK_MyTable] PRIMARY KEY ([Id])
)
When there should be a [dbo] tucked in there like this:
CREATE TABLE [dbo].[MyTable] (
[Id] [int] NOT NULL IDENTITY,
[MyProp1] [nvarchar](max),
[MyProp2] [nvarchar](max),
CONSTRAINT [PK_MyTable] PRIMARY KEY ([Id])
)
Has anyone else had luck in getting Entity Framework to respect the schema? This behavior pretty much kills our ability to use codefirst at all in our enterprise environment.
Reminder: Changing my user to have a different default schema is not an option at all.
As my comment seems to have answered the quandary, I am recreating it as an answer.
It seems that because the SQL Server provider uses "dbo" as the default schema, it will not explicitly add "dbo" to the TSQL that creates the tables even if you specify that in your configuration.
This answers the basic problem. But now I am curious if dbo is the default, do you (Bob) still have a reason to specify it? It doesn't hurt to have it in the configuration if you just want the default to be obvious to someone reading the code. But is the behavior creating another side-effect?
ADDED: Aha! FIXED IN EF5! :) (I just updated my test project to use EF5RC (against .NET 4.0) and I got "dbo" explicitly in the TSQL for create table.)
I tried all of the stuff that Bob Bland tried with a similar lack of success (I was also using Entity Framework 4.3.1 CodeFirst). Then I changed the generated migration to look like this and it worked. Maybe this will save somebody a few minutes of pain?
So my solution was to generate the migration as normal, then hack it by hand to include dbo. as shown below.
public override void Up()
{
CreateTable(
"dbo.UploadedFiles", // See? I have added dbo. to the front of my table name :-)
c => new
{
UploadedFileId = c.Guid(nullable: false, identity: true),
// other columns omitted for brevity...
FileData = c.Binary(),
})
.PrimaryKey(t => t.UploadedFileId);
}
and the Down bit looks like this
public override void Down()
{
DropTable("dbo.UploadedFiles"); // See? I have added dbo. to the front of my table name here too :-)
}