I added EntityFramework.Migrations (Beta 1) to an existing Code-First app that is going through some changes (for both migration capabilities and more fine-tuning of the tables I am generating from my code-first API) and ran into the GETDATE() scenario.
I was already using a custom initializer class in my DbContext to run SQL scripts to set some fields and create indexes in my database. A handful of my AlterTable scripts are primary just to setup fields with default values(such as certain DateTime fields being set to GETDATE()). I was really hoping EntityFramework.Migrations would have an answer for this since you can easily specify defaultValue, but so far I'm not seeing one.
Any ideas? I was really hoping that doing the following would magically work. (It is 'magic unicorn', after all)
DateCreated = c.DateTime(nullable: false, defaultValue: DateTime.Now)
Unfortunately, and logically, it set my default value to the time when the Update-Database command was executed.
You can use
DateCreated = c.DateTime(nullable: false, defaultValueSql: "GETDATE()")
Usage:
public partial class MyMigration : DbMigration
{
public override void Up()
{
CreateTable("dbo.Users",
c => new
{
Created = c.DateTime(nullable: false, defaultValueSql: "GETDATE()"),
})
.PrimaryKey(t => t.ID);
...
Update 2012-10-10:
As requested by Thiago in his comment, I add a little extra context.
The code above is a migration-file generated by EF Migrations by running Add-Migration MyMigration as a command in the package manager console. The generated code is based on the models in the DbContext associated with migrations. The answer suggests that you modify the generated script so that a default value is added when the database is created.
You can read more about Entity Framework Code First Migrations here.
I recently ran in to this issue in EF6 (since they still haven't fixed it). The easiest way I found to do it without having to manually modify the Migration class is to override the CodeGenerator in your Configuration class.
By creating a class that implements MigrationCodeGenerator and then overriding the Generate method you can iterate through all of the operations and apply what ever modifications you want.
Once your modifications have been made, you can then initialize your the CSharpMigrationCodeGenerator and return its default value.
public class ExtendedMigrationCodeGenerator : MigrationCodeGenerator
{
public override ScaffoldedMigration Generate(string migrationId, IEnumerable<MigrationOperation> operations, string sourceModel, string targetModel, string #namespace, string className)
{
foreach (MigrationOperation operation in operations)
{
if (operation is CreateTableOperation)
{
foreach (var column in ((CreateTableOperation)operation).Columns)
if (column.ClrType == typeof(DateTime) && column.IsNullable.HasValue && !column.IsNullable.Value && string.IsNullOrEmpty(column.DefaultValueSql))
column.DefaultValueSql = "GETDATE()";
}
else if (operation is AddColumnOperation)
{
ColumnModel column = ((AddColumnOperation)operation).Column;
if (column.ClrType == typeof(DateTime) && column.IsNullable.HasValue && !column.IsNullable.Value && string.IsNullOrEmpty(column.DefaultValueSql))
column.DefaultValueSql = "GETDATE()";
}
}
CSharpMigrationCodeGenerator generator = new CSharpMigrationCodeGenerator();
return generator.Generate(migrationId, operations, sourceModel, targetModel, #namespace, className);
}
}
internal sealed class Configuration : DbMigrationsConfiguration<Project.Models.Context.DatabaseContext>
{
public Configuration()
{
AutomaticMigrationsEnabled = false;
MigrationsDirectory = #"Migrations";
this.CodeGenerator = new ExtendedMigrationCodeGenerator();
}
}
I hope this helps
You must use custom SQL script in Up method for setting default value:
Sql("ALTER TABLE TableName ADD CONSTRAINT ConstraintName DEFAULT GETDATE() FOR ColumnName");
Setting default value in code allows only static values - no database level functions.
Anyway setting it in POCO constructor is correct way if you are going to use code first. Also if you want to set the value in the application for some special cases you cannot use a default value in the database because the default value in the database requires either DatabaseGeneratedOption.Identity or DatabaseGeneratedOption.Computed. Both these options allow setting the property only in the database.
Edit:
Since the product is still in development my answer is no longer valid. Check #gius answer for actual way to achieve this requirement by using defaultValueSql (it wasn't available in EF Migrations Beta 1 but was added in EF 4.3 Beta 1 which already includes migrations).
Create a migration:
public partial class Table_Alter : DbMigration
{
public override void Up()
{
AddColumn("dbo.tableName", "columnName",
c => c.DateTime(nullable: false, defaultValueSql: "GETDATE()"));
}
public override void Down()
{
DropColumn("dbo.tableName", "columnName");
}
}
For existing records it will set the datetime when you will run Update-Database command, for new records it will be set the datetime of creation
Alternatively if your entities inherit from a common interface you can override the SaveChanges method on the DbContext and set or update properties at that point (great for Created Date and Last Changed Date)
This is the most simple way.
First Add DatabaseGeneratedOption.Computed DataAnnotion to your property
and now you can modify de SqlServerMigrationSqlGenarator, override Genarate method and set the DefaultValueSql = "GETDATE()" or "GETUTCDATE()";
Using Entity Framework with .net 6 I was able to make the migration add the default time by changing the defaultValue to defaultValueSql:
public partial class ReportQueueAddCreatedAt : Migration
{
protected override void Up(MigrationBuilder migrationBuilder)
{
migrationBuilder.AddColumn<DateTime>(
name: "CreatedAt",
table: "ReportQueue",
type: "datetime2",
nullable: false,
defaultValueSql: "GETDATE()");
}
protected override void Down(MigrationBuilder migrationBuilder)
{
migrationBuilder.DropColumn(
name: "CreatedAt",
table: "ReportQueue");
}
}
An improvement: check if the constraint exists:
Sql(#"
if not exists (
select *
from sys.all_columns c
join sys.tables t on t.object_id = c.object_id
join sys.schemas s on s.schema_id = t.schema_id
join sys.default_constraints d on c.default_object_id = d.object_id
where
d.name = 'DF_ThubOutputEmail_Created'
)
begin
ALTER TABLE dbo.ThubOutputEmails ADD CONSTRAINT DF_ThubOutputEmail_Created default getdate() for Created;
end");
Related
I want to run an SQL script after each new table created through Entity Framework.
I created an override for 'CreateTableOperation' like this:
protected override void Generate(CreateTableOperation createTableOperation)
{
string tenantID = "tenantID";
base.Generate(createTableOperation);
//If the table contain the column "tenantID",
if ((from x in createTableOperation.Columns
where x.Name == tenantID
select x).Any()
)
{
//Add the Security Policies for this table
using (var writer = Writer())
{
writer.WriteLine("ALTER SECURITY POLICY rls.tenantAccessPolicy ");
//Note: dbo. is already part of the .Name, don't add it manually before .Name
writer.WriteLine($"ADD FILTER PREDICATE rls.fn_tenantAccessPredicateWithSuperUser([{tenantID}]) ON [{createTableOperation.Name}], ");
writer.WriteLine($"ADD BLOCK PREDICATE rls.fn_tenantAccessPredicateWithSuperUser([{tenantID}]) ON [{createTableOperation.Name}] ");
Statement(writer);
}
}
}
Let's say I create a new class 'TEST'.
The problem is when I run my Update-Database in the Package Manager Console, the SQL is executed in one big block and create an error because the table is not yet created and I'm trying to get the table.name Package Manager result after Update-Database:
CREATE TABLE [dbo].[TEST] (
[ID] [int] NOT NULL IDENTITY,
[NameTEST] [nvarchar](max),
[TenantID] [int] NOT NULL,
CONSTRAINT [PK_dbo.TEST] PRIMARY KEY ([ID])
)
ALTER SECURITY POLICY rls.tenantAccessPolicy
ADD FILTER PREDICATE rls.fn_tenantAccessPredicateWithSuperUser([tenantID]) ON [dbo.TEST],
ADD BLOCK PREDICATE rls.fn_tenantAccessPredicateWithSuperUser([tenantID]) ON [dbo.TEST]
Cannot find the object "dbo.TEST" because it does not exist or you do not have permissions.
Is there a way to break between the base.Generate(createTableOperation); and my Statement(writer);? (I already tried multiple things with 'GO' without much success). Or is it that I'm not supposed to put code in that method?
I couldn't find a solution/documentation to separate the code/batch SQL in Generate(CreateTableOperation createTableOperation).
What I did instead was to
generate dynamic SQL scripts in the Generate(CreateTableOperation createTableOperation) method
/// <summary>
/// Generate dynamically named .sql file for CREATE and DROP Security Policies (Row-Level Security (Company can't see/insert data of another company))
/// </summary>
/// <param name="createTableOperation">Default parameter that comes with the override method.</param>
protected override void Generate(CreateTableOperation createTableOperation)
{
base.Generate(createTableOperation);
string fullFolderPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "..\\Migrations\\SQLscripts\\SecurityPolicies");
//Remove the schema for the dynamic creation of the .sql filename else it throw an exception:
int indexOfDot = createTableOperation.Name.IndexOf(".");
indexOfDot++; //Because it's 0 base, add 1 char
string tableNameWithoutSchema = (indexOfDot < 0) ? createTableOperation.Name : createTableOperation.Name.Remove(0, indexOfDot);
string filePathCreate = Path.Combine(fullFolderPath, $"CreateSecurityPolicies_{tableNameWithoutSchema}.sql");
string filePathDrop = Path.Combine(fullFolderPath, $"DropSecurityPolicies_{tableNameWithoutSchema}.sql");
//If .sql files doesn't exists, create them
if (!File.Exists(filePathCreate))
{
using (StreamWriter sw = new StreamWriter(filePathCreate, true))
{
sw.WriteLine("ALTER SECURITY POLICY rls.tenantAccessPolicy");
//Note: Don't concatenate 'dbo.{}' because 'createTableOperation.Name' already include 'dbo'
sw.WriteLine($" ADD FILTER PREDICATE rls.fn_tenantAccessPredicateWithSuperUser(CompanyID) ON {createTableOperation.Name},");
sw.WriteLine($" ADD BLOCK PREDICATE rls.fn_tenantAccessPredicateWithSuperUser(CompanyID) ON {createTableOperation.Name}");
sw.WriteLine("GO");
sw.Close();
}
}
if (!File.Exists(filePathDrop))
{
using (StreamWriter sw = new StreamWriter(filePathDrop, true))
{
sw.WriteLine("ALTER SECURITY POLICY rls.tenantAccessPolicy");
sw.WriteLine($" DROP FILTER PREDICATE ON {createTableOperation.Name},");
sw.WriteLine($" DROP BLOCK PREDICATE ON {createTableOperation.Name}");
sw.WriteLine("GO");
sw.Close();
}
}
}
Then, with my SQL scripts in a folder, add it manually to my solution.
Add-Migration just to run my SQL script by adding code into the empty (up-to-date) migration class.
public override void Up()
{
string sqlFilePath = System.IO.Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "..\\Migrations\\SQLscripts\\CreateSecurityPolicies_Client.sql");
string sqlText = System.IO.File.ReadAllText(sqlFilePath);
Sql(sqlText);
}
public override void Down()
{
string sqlFilePath = System.IO.Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "..\\Migrations\\SQLscripts\\DropSecurityPolicies_Client.sql");
string sqlText = System.IO.File.ReadAllText(sqlFilePath);
Sql(sqlText);
}
This is the best I can come up with for the moment. I hope it can helps other EntityFramework programmers!
I'm using Entity Framework and I had to add some migrations. Now I'd like to update a customer's app and database.
I considered using update-database -script -SourceMigration migrationName command which doesn't work because I create a view in one of my migrations and it gives me the following exception in VS Console.
There is already an object named 'viewName' in the database.
It seems migrate.exe can be used too, but I'm not much familiar with its function and I prefer not to install anything on the customer's computer (because of limited access).
What's the best way to apply those migrations? I prefer to do it with a SQL script, but I can't get ride of that exception.
The migration code of the view:
public override void Up()
{
string script = #"CREATE VIEW [dbo].[viewName]
AS
SELECT *
FROM dbo.existingTable
WHERE (subquery)";
using (var db = new EFDbContext())
{
db.Database.ExecuteSqlCommand(script);
}
}
public override void Down()
{
var script = #"DROP VIEW [dbo].[viewName]";
using (var db = new EFDbContext())
{
db.Database.ExecuteSqlCommand(script);
}
}
The better way to add your views is using Sql inside Up and Down which ‘Up’ applies the changes to the target database and ‘Down’ reverts them:
public override void Up()
{
Sql("EXEC ('CREATE View [dbo].[viewName] AS --etc"
}
public override void Down()
{
Sql(#"IF EXISTS (SELECT
*
FROM sys.views
WHERE object_id = OBJECT_ID(N'dbo.viewName'))
DROP VIEW dbo.viewName)")
}
Is there a way to write test for specific versions of the migrations?
Lets say that i have done "add-migration 01 Added column...." -> "08 Deleted column...".
And in my tests i want to see how each and every migration from 01 to 08 is doing.
So, to begin with i want to run all the migrations to the version "01 Added column..." and do a test in that state.
After that i may want to upgrade the database to "05..." and do some testing there.
And last, i want to upgrade the database all the way, and do some finishing tests.
Is this posible with EF Migrations Code first?
Sorry, I don't have an access to EF right now, so my code could not work, but I hope that it can give you a general direction of what you can do.
You can create a custom database initializer:
public sealed class MigrationInitializer : IDatabaseInitializer<MyContext>
{
private readonly string _targetMigration;
public MigrationInitializer()
{
}
public MigrationInitializer(string targetMigration)
{
if (string.IsNullOrEmpty(targetMigration))
{
throw new ArgumentException("targetMigration");
}
_targetMigration = targetMigration;
}
public void InitializeDatabase(MyContext context)
{
var migrationsConfiguration = new DbMigrationsConfiguration<MyContext>
{
AutomaticMigrationsEnabled = false
};
var migrator = new DbMigrator(migrationsConfiguration);
if (_targetMigration == null)
{
migrator.Update();
}
else
{
migrator.Update(_targetMigration);
}
}
}
Then force EF to use it in your tests:
System.Data.Entity.Database.SetInitializer<MyContext>(new MigrationInitializer("MyMigration"));
To migrate your database to the latest version you simply use default constructor of MigrationInitializer class.
Note that you can perform both upgrading and downgrading of your database using this method.
I am working on asp.net MVC 3 application and I am using codeFirst approach. I am trying to create history table or user table, Where I want to keep track of what columns were modified by user. How can I do this using EF Code First.
Do I need to do it after DataContext.savechanges ?
Please suggest.
Thanks.
The DbContext has a method called Entry<T>:
var entity = context.Items.Find(id);
entity.Name = "foobar";
var entry = context.Entry<Item>(entity);
entry will be of type DbEntityEntry<T> and has the properties OriginalValues and CurrentValues.
You could probably write something that will generically inspect these properties to see what has changed and then automatically insert a new record into your history table.
Either that, or use database triggers.
I'm not sure if this is really the "appropiate" way to do it, but this is how its usually done in sql:
Create an extra property version of type int or something.
Because you probably do not want to loop every time, add another property IsLatestVersion of type bool
When an entity is saved, check if the entity already exists. If so, set the entity on IsLatestVersion = false.
Increment the version, and save the changes as new entity.
Sounds to me like you want an a filter that inherits from ActionFilterAttribute. In my case, this is the simplest example that I have. This is my model, notice that the attributes dictate the mapping to the database.
[Table("UserProfile")]
public class UserProfile
{
[Key, DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
public int UserId { get; set; }
public string UserName { get; set; }
}
In my case, it was as simple as the following, although it was not historical:
public sealed class UsersContext : DbContext
{
public UsersContext() : base("DefaultConnection")
{
}
public DbSet<UserProfile> UserProfiles { get; set; }
}
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
LazyInitializer.EnsureInitialized(ref _initializer, ref isInitialized, ref initializerLock);
}
public void CheckDatabase()
{
Database.SetInitializer<YourDBContextType>(null);
using (var context = new YourDBContextType())
{
if (!context.Database.Exists())
{
((IObjectContextAdapter)context).ObjectContext.CreateDatabase();
}
}
// Uses your connection string to build the following table.
WebSecurity.InitializeDatabaseConnection("DefaultConnection", "UserProfile", "UserId", "UserName", autoCreateTables: true);
}
The end result is not only EF being code first, but also allows for your models for your views to use primitives derived from your complex entities. Now, if you have another, lets say historical, DBContext then I would recommend modifying either the text transformation file or creating a base class for your entities. Both ways allow for an easy generation of code that could insert into your table, then follow up with that entity, clone it into a historical model and save. All that being said, I am a fan of database first approaches with concentration on constraints, triggers, etc. instead of a framework.
Using Entity Framework 4 CTP5 Code First and this example
Is it possible to access the discriminator value?
I would like to use it in a projection like
context.BillingDetails.Select(x => new { Number = x.Number, DiscrimitatorValue = /* how do I get the discriminator value? */ });
From this post I understand the discriminator cannot be mapped to a property but is there any other way of accessing it?
I may be late to the game on this one, but I just added a getter property to the base class that returned the name of the current type:
public string DiscriminatorValue {
get {
return this.GetType().Name;
}
}
Since by default EF is going to use this same value for the Discriminator field, they will match up.
In EF Core 2.1 (I haven't checked previous versions) it's enough to add Discriminator to the base abstract class as private set property. It will be mapped with adequate value.
public abstract class Entity
{
public int Id { get; set; }
public string Discriminator { get; private set; }
}
EF by itself will automatically insert appropriate discriminator value to the database and will automatically set it to an object on read.
After further information from Morteza Manavi in the comments of his post the simple answer is no
you should be aware that the discriminator column is used internally by Code First and you cannnot read/write its values from an inheritance mapping standpoint.
To access the discriminator I would have to execute a SqlQuery against the database or change my mapping strategy.
Reason aside, I recently ran into the same problem but believe this is still relevant for v4 of the EF Framework.
First, create a view which selects the discriminator value into two columns.
create view dbo.vw_BillingDetail
as
select BillingDetailId, DiscriminatorValue, DiscriminatorValue as DiscriminatorValue2 from dbo.BillingDetail
go
Secondly, map the view to your entity during context creation:
modelBuilder
.Entity<BillingDetail>()
.HasKey(n => n.BillingDetailId)
.Map(map =>
{
map.ToTable("vw_Person");
})
Thirdly, define your discriminator mapping for your derived class using one of the columns in your view:
.Map<MyDerivedBillingDetail>(map =>
{
map.Requires("DiscriminatorValue2").HasValue("YourValue");
})
Finally, define a getter and a private setter for the other discriminator column in your view with the DatabaseGenerated annotation set as Computed to prevent EF from updating/inserting for this field:
class BillingDetail
{
public BillingDetailId { get; set; }
[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
public DiscriminatorValue { get; private set; }
}
You can change the private setter to be protected and set this value explicitly during the construction of your derived entities so that the discriminator has a value prior to being persisted:
class MyDerivedBillingDetail : BillingDetail
{
public MyDerivedBillingDetail()
{
this.DiscriminatorValue = "MyValue";
}
}
To expand on #Michael Black's answer for Entity Framework Core 2.1 (earlier? tested in 2.1.4)
You can use any property name, database field name and data type you want.
Create a property:
[Column("foo_type_id")]
class Foo {
public FooTypesEnum TypeId {get; set;}
}
Then in your context class with the fluent API via modelBuilder:
modelBuilder.Entity<Foo>(b => {
b.HasDiscriminator(foo => foo.TypeId)
.HasValue<SubFooA>(FooTypesEnum.SubFooA)
.HasValue<SubFooB>(FooTypesEnum.SubFooB);
});
This is really useful if you need to build composable queries that e.g., group on the discriminator, etc.
Why don't you use the following query instead?
var q = con.BillingDetails.OfType<BankAccount>().ToList();
You can add a property with the name you gave to the discriminator in EF Core. Example:
In DBContext:
...HasDiscriminator<string>("Type")..
In base class do:
public string Type { get; private set; }