Quantcast
Channel: Entity Framework
Viewing all 10318 articles
Browse latest View live

Closed Issue: LOC Designer - When creating a new entity the default key name is "ID" whereas on english it's "Id" [455]

0
0
There is inconsitency in the default name for Key property. In English local it's "Id", in localized bits (checked on German and Japanase) its "ID"
Comments: **EF Team Triage:** We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base. Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). **Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).** This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include: * It was a bug report that does not contain sufficient information for us to be able to reproduce it * It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it * It is a feature request that we are realistically not going to implement on the EF6.x code base Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). **We will no longer be monitoring this issue tracker for comments, so please do not reply here.**

Closed Issue: UpForGrabs: Designer - inconsistency in naming properties between ComplexType and EntityType [456]

0
0
When using a designer to add a new property to a complex type, the default name is Property (or ComplexProperty for complex ones). In the case of entities its Property1 or NavigationProperty1.

Expected: Naming pattern should be consistent across the board.
Comments: **EF Team Triage:** We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base. Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). **Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).** This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include: * It was a bug report that does not contain sufficient information for us to be able to reproduce it * It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it * It is a feature request that we are realistically not going to implement on the EF6.x code base Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). **We will no longer be monitoring this issue tracker for comments, so please do not reply here.**

Closed Issue: LOC Designer - inconsistency in default naming when adding new entity and complex type [457]

0
0
When adding new entity in EF Designer, the default Entity name is localzed (Entität1 for German run). However, the default name for complex type is not localized - ComplexType1, neither are the default names of properies. We should be consistent there.
Comments: **EF Team Triage:** We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base. Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). **Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).** This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include: * It was a bug report that does not contain sufficient information for us to be able to reproduce it * It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it * It is a feature request that we are realistically not going to implement on the EF6.x code base Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). **We will no longer be monitoring this issue tracker for comments, so please do not reply here.**

Closed Issue: [Loc Designer] Inconsistency in the localized menu items in German, Japanese, and Korean [459]

0
0

functionmapping.png -> Only the Function in the Update Function is localized in Korean. It should be revert back as in the Insert Function and the Delete Function. In 2010, it was not localized.

Comments: **EF Team Triage:** We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base. Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). **Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).** This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include: * It was a bug report that does not contain sufficient information for us to be able to reproduce it * It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it * It is a feature request that we are realistically not going to implement on the EF6.x code base Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). **We will no longer be monitoring this issue tracker for comments, so please do not reply here.**

Closed Issue: UpForGrabs: Export data as C# / VB format to use them in EF Code First's seed data [442]

0
0
Some times, sample data is important but boring to generate due to many related tables. So, in Entity Framework Code First, I think it's an elegant way to insert them in DropCreateDatabaseIfModelChanges::Seed().

But is there a way to export existing data from database back to a string as C# / VB sentences that insert poco objects?

If it works, we may use it to backup data gracefully, or save to multiple .cs by scenes, switch them as needed to better our test, etc.

DATABASE EXPORTS AS THE FOLLOWING CODE:

var students = new List<Student>
{
new Student { FirstMidName = "Carson", LastName = "Alexander", },
new Student { FirstMidName = "Meredith", LastName = "Alonso", },
new Student { FirstMidName = "Arturo", LastName = "Anand", },
// ...
};
students.ForEach(s => context.Students.Add(s));
context.SaveChanges();
Comments: **EF Team Triage:** We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base. Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). **Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).** This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include: * It was a bug report that does not contain sufficient information for us to be able to reproduce it * It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it * It is a feature request that we are realistically not going to implement on the EF6.x code base Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). **We will no longer be monitoring this issue tracker for comments, so please do not reply here.**

Closed Issue: Creating 2 EDMXs from same DB causes 1st .tt file to "lose" nested classes [380]

0
0
Create an EDMX called Model1.edmx from (say) Northwind importing all tables. You will create (amongst others) a Model1.tt file which will generate a .cs file for each entity Category.cs, Customer.cs etc.

Now create another EDMX called Model2.edmx from the same DB for the same tables. You will create Model2.tt. But Model2.tt also generates Category.cs, Customer.cs etc.

But part of the codegen process is to nest the generated .cs files (Category.cs, Custoemr.cs etc) under Model2.tt. This means that if you return to Model1.tt the only file now nested under that is Model1.cs. All the entity classes have been "moved" to be nested under Model2.tt.
Comments: **EF Team Triage:** We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base. Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). **Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).** This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include: * It was a bug report that does not contain sufficient information for us to be able to reproduce it * It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it * It is a feature request that we are realistically not going to implement on the EF6.x code base Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). **We will no longer be monitoring this issue tracker for comments, so please do not reply here.**

Commented Issue: 6.1.3 Inheritance Bug (6.1.1 works fine) [2798]

0
0
With this model

public class Class1
{
[Key]
public int Id { get; set; }

public virtual string MyProperty { get; set; }
// other properties
}

public class Class3 : Class1
{
[Required]
public override string MyProperty { get; set; }

public string Class3Prop { get; set; }
}


public class TestContext : DbContext
{
public TestContext(DbConnection connection) : base(connection, true) { }

public DbSet<Class1> C1s { get; set; }
public DbSet<Class3> C3s { get; set; }


}

I expect that Class3.MyProperty is required and Class1.MyProperty is not required.

With EF 6.1.1 everything's working fine (in SQL Server the MyProperty field is nullable).
With EF 6.1.3 both Class3.MyProperty and Class1.MyProperty are interpreted as Required (and in SQL Server MyProperty field is not nullable)

Comments: in 6.1.1 most facets configured on the derived type were ignored, this was fixed in 6.1.2. The reported behavior is by design, the workaround is to configure the property using Fluent API: ```C# modelBuilder.Entity<Class3>().Property(c => c.MyProperty).IsOptional(); ```

Created Unassigned: Support DateTimeOffset.DateTime and DateTime.Date properties. [2963]

0
0
I'm finding it next to impossible to get the local DateTime component of a DateTimeOffset in entity framework. It must use a "cast(x as datetime2(7))" as opposed to a convert, because any kind of conversion typically treats it as a UTC time. Alternatively, add DbFunctions.TruncateOffset. There is already a TruncateTime function, but that's useless, because it truncates the time and keeps the offset. I need a method that truncates the offset and keeps the time, so that I can query for the local part of the DateTimeOffset field.

Commented Unassigned: Support DateTimeOffset.DateTime and DateTime.Date properties. [2963]

0
0
I'm finding it next to impossible to get the local DateTime component of a DateTimeOffset in entity framework. It must use a "cast(x as datetime2(7))" as opposed to a convert, because any kind of conversion typically treats it as a UTC time. Alternatively, add DbFunctions.TruncateOffset. There is already a TruncateTime function, but that's useless, because it truncates the time and keeps the offset. I need a method that truncates the offset and keeps the time, so that I can query for the local part of the DateTimeOffset field.
Comments: var startDate = new DateTime(2016,12,15,8,0,0); //Dec 15, 2016 8:00AM Assuming 'StartInstant' is a nullable DateTimeOffset field, I'd like to be able to do one of these: If you added support for the DateTIme property of DateTimeOffset: query.Where(x => x.StartInstant.Value.DateTime >= startDate); If you added DbFunctions method "DateTime? TruncateOffset(DateTimeOffset?)": query.Where(x => DbFunctions.TruncateOffset(x.StartInstant) >= startDate); Currently my only option is this monster, which also loses some precision: query.Where(x => DbFunctions.CreateDateTime(x.StartInstant.Value.Year, x.StartInstant.Value.Month, x.StartInstant.Value.Day, x.StartInstant.Value.Hour, x.StartInstant.Value.Minute, x.StartInstant.Value.Second) >= startDate);

Edited Unassigned: Support DateTimeOffset.DateTime and DateTime.Date properties. [2963]

0
0
I'm finding it next to impossible to get the local DateTime component of a DateTimeOffset in entity framework. It must use a "cast(x as datetime2(7))" as opposed to a convert, because any kind of conversion typically treats it as a UTC time. Alternatively, add DbFunctions.TruncateOffset. There is already a TruncateTime function, but that's useless, because it truncates the time and keeps the offset. I need a method that truncates the offset and keeps the time, so that I can query for the local part of the DateTimeOffset field.



var startDate = new DateTime(2016,12,15,8,0,0); //Dec 15, 2016 8:00AM

Assuming 'StartInstant' is a nullable DateTimeOffset field, I'd like to be able to do one of these:

If you added support for the DateTIme property of DateTimeOffset:
query.Where(x => x.StartInstant.Value.DateTime >= startDate);
//Generated SQL... "where cast(StartInstant as datetime2(7)) >= @p__linq__0"

If you added DbFunctions method "DateTime? TruncateOffset(DateTimeOffset?)":
query.Where(x => DbFunctions.TruncateOffset(x.StartInstant) >= startDate);
//Generated SQL... "where cast(StartInstant as datetime2(7)) >= @p__linq__0"

Currently my only option is this monster, which also loses some precision and generates what surely is nasty index-busting SQL for the field:
query.Where(x => DbFunctions.CreateDateTime(x.StartInstant.Value.Year, x.StartInstant.Value.Month, x.StartInstant.Value.Day, x.StartInstant.Value.Hour, x.StartInstant.Value.Minute, x.StartInstant.Value.Second) >= startDate);
//Generated SQL (yes, seriously>>>)... ((convert (datetime2,right(''000'' + convert(varchar(255), DATEPART (year, [Extent1].[StartInstant])), 4) + ''-'' + convert(varchar(255), DATEPART (month, [Extent1].[StartInstant])) + ''-'' + convert(varchar(255), DATEPART (day, [Extent1].[StartInstant])) + '' '' + convert(varchar(255), DATEPART (hour, [Extent1].[StartInstant])) + '':'' + convert(varchar(255), DATEPART (minute, [Extent1].[StartInstant])) + '':'' + str( CAST( DATEPART (second, [Extent1].[StartInstant]) AS float), 10, 7), 121)) >= @p__linq__0

Commented Unassigned: Support DateTimeOffset.DateTime and DateTime.Date properties. [2963]

0
0
I'm finding it next to impossible to get the local DateTime component of a DateTimeOffset in entity framework. It must use a "cast(x as datetime2(7))" as opposed to a convert, because any kind of conversion typically treats it as a UTC time. Alternatively, add DbFunctions.TruncateOffset. There is already a TruncateTime function, but that's useless, because it truncates the time and keeps the offset. I need a method that truncates the offset and keeps the time, so that I can query for the local part of the DateTimeOffset field.



var startDate = new DateTime(2016,12,15,8,0,0); //Dec 15, 2016 8:00AM

Assuming 'StartInstant' is a nullable DateTimeOffset field, I'd like to be able to do one of these:

If you added support for the DateTIme property of DateTimeOffset:
query.Where(x => x.StartInstant.Value.DateTime >= startDate);
//Generated SQL... "where cast(StartInstant as datetime2(7)) >= @p__linq__0"

If you added DbFunctions method "DateTime? TruncateOffset(DateTimeOffset?)":
query.Where(x => DbFunctions.TruncateOffset(x.StartInstant) >= startDate);
//Generated SQL... "where cast(StartInstant as datetime2(7)) >= @p__linq__0"

Currently my only option is this monster, which also loses some precision and generates what surely is nasty index-busting SQL for the field:
query.Where(x => DbFunctions.CreateDateTime(x.StartInstant.Value.Year, x.StartInstant.Value.Month, x.StartInstant.Value.Day, x.StartInstant.Value.Hour, x.StartInstant.Value.Minute, x.StartInstant.Value.Second) >= startDate);
//Generated SQL (yes, seriously>>>)... ((convert (datetime2,right(''000'' + convert(varchar(255), DATEPART (year, [Extent1].[StartInstant])), 4) + ''-'' + convert(varchar(255), DATEPART (month, [Extent1].[StartInstant])) + ''-'' + convert(varchar(255), DATEPART (day, [Extent1].[StartInstant])) + '' '' + convert(varchar(255), DATEPART (hour, [Extent1].[StartInstant])) + '':'' + convert(varchar(255), DATEPART (minute, [Extent1].[StartInstant])) + '':'' + str( CAST( DATEPART (second, [Extent1].[StartInstant]) AS float), 10, 7), 121)) >= @p__linq__0
Comments: Lack of this feature is a HUGE oversight. Without it, DateTimeOffset type is useless, because it cannot be treated as anything other than a normal UTC time in linq-to-entity queries, and so it defeats the purpose of having a separate datetime component and offset component, because you cannot inspect the local datetime component of the field in any way.

Commented Issue: NotMapped on base property throws if derived type discovered first [481]

0
0
An exception is thrown when the derived entity type is discovered before the base entity type containing an ignored property.

"You cannot use Ignore method on the property 'BaseProperty' on type 'DerivedEntity' because this type inherits from the type 'BaseEntity' where this property is mapped. To exclude this property from your model, use NotMappedAttribute or Ignore method on the base type."

var modelBuilder = new DbModelBuilder();
modelBuilder.Entity<DerivedEntity>();
modelBuilder.Entity<BaseEntity>();
modelBuilder.Build(new DbProviderInfo("System.Data.SqlClient", "2008"));

public class BaseEntity
{
public long Id { get; set; }
[NotMapped]
public string BaseProperty { get; set; }
}

public class DerivedEntity : BaseEntity
{
}

## WORKAROUND ##

Here's the algorithm to fix your code if you get the exception "You cannot use Ignore method on the property 'PropertyX' on type 'TypeY' because this type inherits from the type 'TypeZ' where this property is mapped. To exclude this property from your model, use NotMappedAttribute or Ignore method on the base type.":

1. Are you calling modelBuilder.Entity<TypeY>().Ignore(p => p.PropertyX);?
Yes. Replace this call with modelBuilder.Entity<TypeZ>().Ignore(p => p.PropertyX);
Goto 3.
No. Goto 2.
2. There should be a NotMapped attribute on property 'PropertyX' that's defined on 'TypeZ'. Is 'TypeZ' included in the model? (i.e. it's a valid entity type and it isn't ignored)
Yes. Ensure that 'TypeZ' is discovered before 'TypeY', to do this put modelBuilder.Entity<TypeZ>(); before modelBuilder.Entity<TypeY>();
Goto 3.
No. Remove NotMapped attribute from property 'PropertyX'. For each 'TypeW' directly derived from 'Z' add modelBuilder.Entity<TypeW>().Ignore(p => p.PropertyX);
Goto 3.
3. Run your tests. Did you get another exception with the same text, but different types?
Yes. Goto 1.
No. Enjoy!


Comments: __A Workaround that Helped Me__ Part of the domain model of my project consists of the following structure: ``` public enum PocoState { ... } public abstract class User { public PocoState PocoState { get; set; } // should not be mapped } public class Employee : User{} public class Customer : User{} ``` I have configuration classes derived from __EntityTypeConfiguration__ class in a separate assembly as follows: ``` public class UserConfig : EntityTypeConfiguration<User> { Ignore(p => p.PocoState); } public class EmployeeConfig : EntityTypeConfiguration<Employee> { public EmployeeConfiguration() { // All needed configurations except Ignore(p => p.PocoState) } } public class CustomerConfiguration : EntityTypeConfiguration<Customer> { public CustomerConfiguration() { // All needed configurations except Ignore(p => p.PocoState) } } ``` Then I add these configuration classes to the OnModelCreating method inside DbContext class. My DbContext class is like below ``` public class MyDbContext : DbContext { public DbSet<Employee> Employees { get; set; } public DbSet<Customer> Customers { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Configurations.AddFromAssembly(Assembly.GetAssembly(typeof(UserConfig))); base.OnModelCreating(modelBuilder); } } ``` HTH

Commented Issue: NotMapped on base property throws if derived type discovered first [481]

0
0
An exception is thrown when the derived entity type is discovered before the base entity type containing an ignored property.

"You cannot use Ignore method on the property 'BaseProperty' on type 'DerivedEntity' because this type inherits from the type 'BaseEntity' where this property is mapped. To exclude this property from your model, use NotMappedAttribute or Ignore method on the base type."

var modelBuilder = new DbModelBuilder();
modelBuilder.Entity<DerivedEntity>();
modelBuilder.Entity<BaseEntity>();
modelBuilder.Build(new DbProviderInfo("System.Data.SqlClient", "2008"));

public class BaseEntity
{
public long Id { get; set; }
[NotMapped]
public string BaseProperty { get; set; }
}

public class DerivedEntity : BaseEntity
{
}

## WORKAROUND ##

Here's the algorithm to fix your code if you get the exception "You cannot use Ignore method on the property 'PropertyX' on type 'TypeY' because this type inherits from the type 'TypeZ' where this property is mapped. To exclude this property from your model, use NotMappedAttribute or Ignore method on the base type.":

1. Are you calling modelBuilder.Entity<TypeY>().Ignore(p => p.PropertyX);?
Yes. Replace this call with modelBuilder.Entity<TypeZ>().Ignore(p => p.PropertyX);
Goto 3.
No. Goto 2.
2. There should be a NotMapped attribute on property 'PropertyX' that's defined on 'TypeZ'. Is 'TypeZ' included in the model? (i.e. it's a valid entity type and it isn't ignored)
Yes. Ensure that 'TypeZ' is discovered before 'TypeY', to do this put modelBuilder.Entity<TypeZ>(); before modelBuilder.Entity<TypeY>();
Goto 3.
No. Remove NotMapped attribute from property 'PropertyX'. For each 'TypeW' directly derived from 'Z' add modelBuilder.Entity<TypeW>().Ignore(p => p.PropertyX);
Goto 3.
3. Run your tests. Did you get another exception with the same text, but different types?
Yes. Goto 1.
No. Enjoy!


Comments: In the above example I forgot to put the code ijnside the ctor of the UserConfig class. Please consider the following code as the correct fragment: ``` public class UserConfig : EntityTypeConfiguration<User> { public UserConfig() { Ignore(p => p.PocoState); } } ```

Reviewed: EF 6.1.3 (十二月 16, 2016)

0
0
Rated 5 Stars (out of 5) - Very Helpful

Commented Unassigned: EF 6 - Bug concerning new connection resiliency feature (.Net 4.5) - Performance Problem [2899]

0
0
When using the same DbContext class (e.g. DbContext itself) with different connection strings, the Connection Resiliency Feature of .Net 4.5 causes DB-creation to take a long time (due to the DB-Existency checks).

I made a small repro sample where you can see the different effects.
Basically when using 2 default connection strings (without modified connection resiliency settings) with the same DbContext class, the second DB-Creation takes >10s (as this seems to be the default ConnectRetryInterval, even when the MSDN docs suggest something else).

**Repro sample**
```C#
static void Main (string[] args)
{
// Default resiliency settings (since .NET 4.5)
var defaultConnectionString = "Data Source=localhost;Initial Catalog=EFIdleResiliencyBug1;Integrated Security=SSPI";

// Retry Interval = 3s (instead of 10 which seems to be the default)
var connectionStringThreeSeconds = "Data Source=localhost;Initial Catalog=EFIdleResiliencyBug2;Integrated Security=SSPI;ConnectRetryInterval=3";

// Retry Count = 0 (instead of 1) => means Resiliency Feature is disabled.
var connectionStringZeroRetry = "Data Source=localhost;Initial Catalog=EFIdleResiliencyBug3;Integrated Security=SSPI;ConnectRetryCount=0;";

// Here we also create a default connection string but with a different db
var defaultConnectionString2 = "Data Source=localhost;Initial Catalog=EFIdleResiliencyBug4;Integrated Security=SSPI";

//The first DB that is dropped is seemingly stored statically in EF.
Drop(defaultConnectionString);
Drop(connectionStringZeroRetry);
Drop (connectionStringThreeSeconds);
Drop (defaultConnectionString2);

//The stored dropped connection string can be recreated very fast.
Create(defaultConnectionString);

//All other connection strings (same DbContext class) try to connect to the DB.
Create (connectionStringThreeSeconds); // BUG: Takes 3s
Create(connectionStringZeroRetry); // Takes no time (connection resiliency disabled)
Create (defaultConnectionString2); // BUG: Takes 10s (seems to be the default RetryInterval for some reason).

// Note: When using a different derived class from DBContext for each connection string the bug does not exist.

// Expected Behavior: Ignore connection resiliency for checking if the db exists. (It should not take 3s or even 10s).
// This is especially a problem when executing integration / unit tests that drop the db at the beginning.
}

private static void Create (string connectionString)
{
Console.WriteLine ($"Creating {connectionString}");
var sw = Stopwatch.StartNew();

using (var dbContext = new DbContext (connectionString))
{
dbContext.Database.CreateIfNotExists();
Console.WriteLine ("Creating DB took: " + sw.Elapsed);
}
}

private static void Drop (string connectionString)
{
Console.WriteLine ($"Droping {connectionString}");
var sw = Stopwatch.StartNew();

using (var dbContext = new DbContext (connectionString))
{
sw = Stopwatch.StartNew();
dbContext.Database.Delete();

Console.WriteLine ("Deleting DB took: " + sw.Elapsed);
}
}
```

I hope this helps you fix the API or adapt the docs.

But in my opinion the current API (EF6) suggests that you can use the same class (DBContext) for multiple connection strings (ctor for this). However with .Net 4.5 that causes serious performance problems.
This is especially noticable in our unit / integration tests where we drop multiple DBs with the same DBContext class and recreate them later.
Comments: Reproduced in EF Core (https://github.com/aspnet/EntityFramework/issues/7283)

Commented Unassigned: Support DateTimeOffset.DateTime and DateTime.Date properties. [2963]

0
0
I'm finding it next to impossible to get the local DateTime component of a DateTimeOffset in entity framework. It must use a "cast(x as datetime2(7))" as opposed to a convert, because any kind of conversion typically treats it as a UTC time. Alternatively, add DbFunctions.TruncateOffset. There is already a TruncateTime function, but that's useless, because it truncates the time and keeps the offset. I need a method that truncates the offset and keeps the time, so that I can query for the local part of the DateTimeOffset field.



var startDate = new DateTime(2016,12,15,8,0,0); //Dec 15, 2016 8:00AM

Assuming 'StartInstant' is a nullable DateTimeOffset field, I'd like to be able to do one of these:

If you added support for the DateTIme property of DateTimeOffset:
query.Where(x => x.StartInstant.Value.DateTime >= startDate);
//Generated SQL... "where cast(StartInstant as datetime2(7)) >= @p__linq__0"

If you added DbFunctions method "DateTime? TruncateOffset(DateTimeOffset?)":
query.Where(x => DbFunctions.TruncateOffset(x.StartInstant) >= startDate);
//Generated SQL... "where cast(StartInstant as datetime2(7)) >= @p__linq__0"

Currently my only option is this monster, which also loses some precision and generates what surely is nasty index-busting SQL for the field:
query.Where(x => DbFunctions.CreateDateTime(x.StartInstant.Value.Year, x.StartInstant.Value.Month, x.StartInstant.Value.Day, x.StartInstant.Value.Hour, x.StartInstant.Value.Minute, x.StartInstant.Value.Second) >= startDate);
//Generated SQL (yes, seriously>>>)... ((convert (datetime2,right(''000'' + convert(varchar(255), DATEPART (year, [Extent1].[StartInstant])), 4) + ''-'' + convert(varchar(255), DATEPART (month, [Extent1].[StartInstant])) + ''-'' + convert(varchar(255), DATEPART (day, [Extent1].[StartInstant])) + '' '' + convert(varchar(255), DATEPART (hour, [Extent1].[StartInstant])) + '':'' + convert(varchar(255), DATEPART (minute, [Extent1].[StartInstant])) + '':'' + str( CAST( DATEPART (second, [Extent1].[StartInstant]) AS float), 10, 7), 121)) >= @p__linq__0
Comments: The only way I've found to work around this without loss of precision is as follows. If I have a DateTimeOffset field in the database named "DTOField" and some static local DateTime value to compare which we'll call variable "localDateTimeToCompare", then the following transform in entity framework will work: var comparison = new DateTImeOffset( localDateTimeToCompare, TimeSpan.Zero ); DbFunctions.AddMinutes(x.DTOField, DbFunctions.GetTotalOffsetMinutes(x.DTOField)) <= comparison; That tricks it into offset the local datetime component of the DateTimeOffset by the offset, so that when it's offset by the offset it ends up with the local time with a zero offset.... that local time with zero offset can then be compared to the value we constructed with a zero offset. However, this is ridiculous to have to do this. Add a DbFunctions.TrucateOffset method that accepts a DateTimeOffset and returns the local DateTime portion.

Reviewed: EF 6.1.3 (Dec 30, 2016)

0
0
Rated 5 Stars (out of 5) - well its awesome as the update is what we need in entity development

Created Unassigned: Migrate from Xml.Linq.XDocument to VersionedModel.VersionedModel [2964]

0
0
Based on previous commits from this repository, we identify that we are migrating the version that uses the type Xml.Linq.XDocument to the type VersionedModel.VersionedModel. For instance, in commit 14623da, you performed 19 edits of this kind: 18 on class HistoryRepositoryTests.cs and 1 on class InternalContext.cs. But other locations in the source code still need to be migrated. Is not it the case to migrate the additional locations?
Link to the commit: [https://entityframework.codeplex.com/SourceControl/changeset/14623da1e612d16c52b331bbd37ac1294c856658](https://entityframework.codeplex.com/SourceControl/changeset/14623da1e612d16c52b331bbd37ac1294c856658)

Reviewed: EF 6.1.3 (二月 20, 2017)

0
0
Rated 5 Stars (out of 5) - 好好好好好好好好好好好

Reviewed: EF 6.0.0 (二月 20, 2017)

0
0
Rated 3 Stars (out of 5) - 1111111111111111111111111
Viewing all 10318 articles
Browse latest View live




Latest Images