Edited Feature: Provide interception & logging events for transactions [1256]

September 24, 2013, 11:22 am

≫ Next: Edited Feature: Add Support for Synonyms [1240]

≪ Previous: Edited Feature: Provide interception & logging events for transactions [1256]

This would be in general useful to customize the behavior, to include transaction details in the log and also to enable the implementation of workarounds for the issue described here:

[Connection resiliency: possible data corruption if connection fails after transaction commit](https://entityframework.codeplex.com/workitem/1114).

↧

Edited Feature: Add Support for Synonyms [1240]

September 24, 2013, 11:24 am

≫ Next: Edited Issue: Designer: After reverse-engineer, datetime columns get Precision "3" in the C-Side [1233]

≪ Previous: Edited Feature: Provide interception & logging events for transactions [1256]

Add a mapping from existing database Synonyms to entities, allow read/write, etc.

I would expect EF to recognize and treat a Synonym exactly the same as it would a Table, or View, etc.

↧

Edited Issue: Designer: After reverse-engineer, datetime columns get Precision "3" in the C-Side [1233]

September 24, 2013, 11:27 am

≫ Next: Edited Feature: Add simple PowerShell command to drop a database [1231]

≪ Previous: Edited Feature: Add Support for Synonyms [1240]

Unlike datetime2 columns, datetime columns do not have precision values. (They have precision set to "(None)" in the S-Side of the model browser.)

However, after being imported from a SQL2012 database, the C-Side properties have precision set to "3", as part of the facet propagation feature. I don't understand the point of this behavior or where the "3" is coming from, and thought it might be a bug.

It is not a regression from the behavior in VS2012, but on a SQL2005 database the datetime column and property both have precision set to "(None)" as I would expect. (Perhaps this was something added to support datetime2 but which inadvertently got applied to datetime columns.)

↧

Edited Feature: Add simple PowerShell command to drop a database [1231]

September 24, 2013, 11:29 am

≫ Next: Created Issue: EF Power Shell commands don't work initially in a common source-control scenario [1682]

≪ Previous: Edited Issue: Designer: After reverse-engineer, datetime columns get Precision "3" in the C-Side [1233]

Currently there are issues with the tooling that ships with various SKUs of Visual Studio that make it hard to delete a database. The first issue is that some SKUs simply don't have any way to delete a database other than writing SQL--see Rowan's post: http://romiller.com/tag/delete-database/

The second issue is that the VS tooling tends to keep a connection to the database open which means that a simple drop command such as that issued by the database initializers will not work. We have already decided that we don't want the initializers to be any more aggressive about attempting to delete a database when something is preventing it.

A further point is that sometimes when using Migrations people want to migrate back down to an empty database but this may break depending on what is setup in the migrations. Often, a solution to this problem is to manually delete the database, but this can be difficult giving the tooling issues.

We don't control the tooling, but these issues could be mitigated if we were to provide a simple PowerShell command that would delete a database associated with a context or Migrations config.

↧

Created Issue: EF Power Shell commands don't work initially in a common source-control scenario [1682]

September 24, 2013, 1:46 pm

≫ Next: Edited Issue: EF Power Shell commands don't work initially in a common source-control scenario [1682]

≪ Previous: Edited Feature: Add simple PowerShell command to drop a database [1231]

Repro steps:

- Create new console application
- Install-Package EntityFramework -Prerelease
- Enable automatic package restore on build
- Build

all works fine - you can use EF power shell commands (Enable-Migrations etc)

now:
- close VS
- delete packages directory,
- open VS
- rebuild (packages should be restored, and they are
- try using EF Power Shell command, e.g. Enable-Migrations

This error pops up:

Enable-Migrations : The term 'Enable-Migrations' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a
path was included, verify that the path is correct and try again.
At line:1 char:1
+ Enable-Migrations
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Enable-Migrations:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

This is quite prevalent in scenarios where using source control - packages folder is usually excluded from source control and this will repro always when downloading sources for the first time.

↧

Edited Issue: EF Power Shell commands don't work initially in a common source-control scenario [1682]

September 24, 2013, 2:02 pm

≫ Next: Source code checked in, #5564d91e1a0de59ab97fdc4403332f0868aa620b

≪ Previous: Created Issue: EF Power Shell commands don't work initially in a common source-control scenario [1682]

Repro steps:

- Create new console application
- Install-Package EntityFramework -Prerelease
- Enable automatic package restore on build
- Build

all works fine - you can use EF power shell commands (Enable-Migrations etc)

now:
- close VS
- delete packages directory,
- open VS
- rebuild (packages should be restored)
- try using EF Power Shell command, e.g. Enable-Migrations

This error pops up:

Enable-Migrations : The term 'Enable-Migrations' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a
path was included, verify that the path is correct and try again.
At line:1 char:1
+ Enable-Migrations
+ ~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Enable-Migrations:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

This is quite prevalent in scenarios where using source control - packages folder is usually excluded from source control and this will repro always when downloading sources for the first time.

↧

Source code checked in, #5564d91e1a0de59ab97fdc4403332f0868aa620b

September 24, 2013, 3:15 pm

≫ Next: Source code checked in, #16c626db382180bf01828bc220858ca6dd4f7f95

≪ Previous: Edited Issue: EF Power Shell commands don't work initially in a common source-control scenario [1682]

Merge branch 'hotfix-6.0.1' Conflicts: src/SharedAssemblyVersionInfo.cs test/EntityFramework/UnitTests/Utilities/AssemblyExtensionsTests.cs tools/EntityFramework.settings.targets

↧

Source code checked in, #16c626db382180bf01828bc220858ca6dd4f7f95

September 24, 2013, 3:15 pm

≫ Next: New Post: Best practices for DbContext in project using IdentityDbContext

≪ Previous: Source code checked in, #5564d91e1a0de59ab97fdc4403332f0868aa620b

Bump version to 6.1.0-alpha1

↧

New Post: Best practices for DbContext in project using IdentityDbContext

September 24, 2013, 4:19 pm

≫ Next: Commented Unassigned: getting "entity types cannot share table" for same-named tables in different schemas [1641]

≪ Previous: Source code checked in, #16c626db382180bf01828bc220858ca6dd4f7f95

When creating a project that uses IdentityDbContext for authentication it is possible to treat this in much the same way as a standard dbContext and use codefirst from within this same context for example:

public class ApplicationDbContext : IdentityDbContextWithCustomUser<ApplicationUser>
{

    public DbSet<Product> Products { get; set; }
    protected override void OnModelCreating(System.Data.Entity.DbModelBuilder modelBuilder)
    {
        modelBuilder.HasDefaultSchema("MyData");
    }
}

Presuming the rest of my data is going to live in the same db Is this the best/expected approach to this or should I simply create a second dbContext for my entities

↧

Commented Unassigned: getting "entity types cannot share table" for same-named tables in different schemas [1641]

September 24, 2013, 4:26 pm

≫ Next: Edited Unassigned: getting "entity types cannot share table" for same-named tables in different schemas [1641]

≪ Previous: New Post: Best practices for DbContext in project using IdentityDbContext

I pulled CF DbContext classes recently created from EF PowerTools 0.7.0.0 in a VS2012/EF 5.0.0 project into a brand new EF 6.0.0-rc1 project. The app worked fine in EF 5.0.0. Now when I attempt to use the DbContext in EF 6.0.0-rc1 I get the "entity types cannot share table" error (even though the fluent configuration for the classes specify the correct ToTable mappings).
Comments: When we configure the model we initially create tables for entities but at that point we don't use configuration yet so we don't have information specified in the .ToTable(). Therefore the tables we create have names corresponding to the source entity type names and don't have the schema set. Later when we configure tables we try to find if any tables matching information from .ToTable() already exists. The way we do the matching is to compare if there is any table we created (and possibly already configured) matches the requested DatabaseName. Note that a table can but does not have to be configured. If a table has already been configured we set an annotation with the full table name (i.e. schema and table name). If a table has not been configured we don't have the schema so we try match only by table name, ignoring the schema. This does not seem correct because the table has not been configured yet and therefore the temporary name we used when creating the table can change after the will have been configured. The configuration depends on the order the entities are discovered. I found that it is enough to swap the two DbSet properties that are causing the issue on the DbContext and the issue goes away. The issue started showing after [a12d50d](ttps://entityframework.codeplex.com/SourceControl/changeset/a12d50d8edb2087d54931a654a34a32fee179367) since in this change we defer configuring navigation properties (and also sort them) effectively changing the order in which entities are configured. Again, I was able to repro this issue on builds preceding the a12d50d by just swapping DbSet properties on the DbContext. This reproes on EF5 so it is not a regression.

↧

Edited Unassigned: getting "entity types cannot share table" for same-named tables in different schemas [1641]

September 24, 2013, 4:27 pm

≫ Next: Edited Issue: [Performance] Code First models still get built more than once in EF6 [1454]

≪ Previous: Commented Unassigned: getting "entity types cannot share table" for same-named tables in different schemas [1641]

↧

Edited Issue: [Performance] Code First models still get built more than once in EF6 [1454]

September 24, 2013, 4:31 pm

≫ Next: Edited Issue: [Performance] GetStorageMappingItemCollection() is more expensive in EF6 [1675]

≪ Previous: Edited Unassigned: getting "entity types cannot share table" for same-named tables in different schemas [1641]

This is the default behavior of Code First in the standard flow of creating a model based on DbContext. The following code demonstrates by showing that a store model convention is applied twice (I have seen it happen 3 times if I am not mistaken):

```
using System;
using System.Data.Entity;
using System.Data.Entity.Core.Metadata.Edm;
using System.Data.Entity.Infrastructure;
using System.Data.Entity.ModelConfiguration.Conventions;

namespace PerfectRehearsal
{
class Program
{
static void Main(string[] args)
{
using(var db = new TownContext())
{
db.Database.Initialize(force: false);
Console.WriteLine(
"Number of times convention was dispatched: {0}",
StoreModelDispatchCounter.Count);
}
}
}

public class Person
{
public int Id { get; set; }
public string Name { get; set; }
}

public class TownContext : DbContext
{
public DbSet<Person> People { get; set; }

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Add(new StoreModelDispatchCounter());
}
}

public class StoreModelDispatchCounter: IStoreModelConvention<EdmModel>
{
public static int Count = 0;

public void Apply(EdmModel item, DbModel model)
{
Count++;
}
}
}

```

↧

Edited Issue: [Performance] GetStorageMappingItemCollection() is more expensive in EF6 [1675]

September 24, 2013, 5:28 pm

≫ Next: Created Unassigned: Remove entity behavior (when we have optional link) [1683]

≪ Previous: Edited Issue: [Performance] Code First models still get built more than once in EF6 [1454]

For a very basic model (Blog, Post, BlogContext) the call to XDocumentExtensions.GetStorageMappingItemCollection() became more expensive in EF6 than it was in EF5. In this small test it went up from 20 samples to 127 samples.
The cost is visible when one generates EF5 and EF6 profiles of the following code:
```
public class Blog
{
public int Id { get; set; }
public string Title { get; set; }

public virtual ICollection<Post> Posts { get; set; }
}

public class Post
{
public int Id { get; set; }
public string Title { get; set; }

public int BlogId { get; set; }
public virtual Blog Blog { get; set; }
}

public class BlogContext : DbContext
{
public DbSet<Blog> Blogs { get; set; }
public DbSet<Post> Posts { get; set; }
}

internal class Program
{
private static void Main(string[] args)
{
//var stopwatch = new Stopwatch();
//stopwatch.Start();
var context = new BlogContext();
context.Posts.Count();
//stopwatch.Stop();
//Console.WriteLine("Model startup time = {0} ms", stopwatch.ElapsedMilliseconds);
}
}
```
This is affecting the performance of method ModelCompatibilityChecker.CompatibleWithModel() which in turn calls to ModelMatches() where this regression is exposed. EF5 calls XDocumentExtensions.GetStoreItemCollection(), EF6 calls to XDocumentExtensions.GetStorageMappingItemCollection() which is more expensive and accounts for the entire increase perceived in ModelMatches().

↧

Created Unassigned: Remove entity behavior (when we have optional link) [1683]

September 25, 2013, 4:12 am

≫ Next: New Post: Best practices for DbContext in project using IdentityDbContext

≪ Previous: Edited Issue: [Performance] GetStorageMappingItemCollection() is more expensive in EF6 [1675]

Have two entities
* SampleEntityA - has optional link to SampleEntityB
/// <summary>
/// Entity with optional link
/// </summary>
public class SampleEntityA : ISampleEntity
{
public Guid Id { get; set; }

public string Name { get; set; }

public SampleEntityB OptionalLink { get; set; }

public Guid? OptionalLinkId { get; set; }
}

* SampleEntityB - simple
/// <summary>
/// Simple entity
/// </summary>
public class SampleEntityB : ISampleEntity
{
public Guid Id { get; set; }

public string Name { get; set; }
}

Steps:

1. Open context
Create B entity
Create A entity (add link to B)
Save changes

2. Open context
Try delete B entity

And there we are get exception

System.Data.Entity.Infrastructure.DbUpdateException : An error occurred while updating the entries. See the inner exception for details.
----> System.Data.Entity.Core.UpdateException : An error occurred while updating the entries. See the inner exception for details.
----> System.Data.SqlClient.SqlException : The DELETE statement conflicted with the REFERENCE constraint "FK_dbo.SampleEntityAs_dbo.SampleEntityBs_OptionalLinkId". The conflict occurred in database "EntityframeWorkTests.DefaultContext", table "dbo.SampleEntityAs", column 'OptionalLinkId'.
The statement has been terminated.

If on second step load A entity (select for example) error not be thrown.

First question - why we have different behavior in equal situations (delete single entity)
Second - after fix, maybe we will choose action on delete? (set null/throw exception)

After fix will be perfect include this feature - choose from "set null/throw exception/cascade delete" for each relationship

Attached solution has NUnit test and console. Run one or another.

↧

New Post: Best practices for DbContext in project using IdentityDbContext

September 25, 2013, 7:01 pm

≫ Next: New Post: Best practices for DbContext in project using IdentityDbContext

≪ Previous: Created Unassigned: Remove entity behavior (when we have optional link) [1683]

Am also really hoping to see guidance on this - seems like the overwhelming number of use-cases hold that the domain's user entities have to bind to the authentication project membership provider - if EF is the ORM then obviously the provider's members are EF entities. So shouldn't we see a walk-thru that demonstrates the Membership Providerwhere the members are DbContext entities?

↧

New Post: Best practices for DbContext in project using IdentityDbContext

September 25, 2013, 10:13 pm

≫ Next: Commented Feature: Allow warm-up to be run async on worker thread [1152]

≪ Previous: New Post: Best practices for DbContext in project using IdentityDbContext

Hello Transacta and Steve,

I am not aware of any fundamental technical reason not to share the DbContext you use with ASP.NET Identity with the rest of your application. In fact, as Steve mentions, in most cases the entities used for identity will play a role in the application's domain anyway and so there are usually more reasons to put them together than to keep them apart.

On the other hand, sometimes an application's domain may grow itself big or complex enough that splitting it into multiple partitions can help improve performance or other qualities such as the understandability and maintainability of the application's code. In those cases using a separate EF model for identity may be the best thing to do.

From a pragmatic perspective I would say that if ASP.NET Identity is flexible enough to accommodate your application's requirements, then most likely doing the simplest thing, i.e. sharing the context, should be your default choice.

I have forwarded your questions to the team working on ASP.NET Identity and they informed me that they have added this subject to their documentation plan.

Hope this helps,
Diego

↧

Commented Feature: Allow warm-up to be run async on worker thread [1152]

September 25, 2013, 10:45 pm

≫ Next: Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]

≪ Previous: New Post: Best practices for DbContext in project using IdentityDbContext

The warm-up time on my DbContext can take several seconds. Calling await on an Async method is useless at that point because the Async methods don't even return until the warm-up is complete and the application still locks up like a poorly coded single threaded application.

The only solution is to abandon the new fangled Async methods altogether and wrap the entire call into a await Task.Run(...).
Comments: So essentially all the async methods perform just the network activity asynchronously?

↧

Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]

September 25, 2013, 11:35 pm

≫ Next: Commented Feature: Make Migrations DB engine independent. [1364]

≪ Previous: Commented Feature: Allow warm-up to be run async on worker thread [1152]

the PropertyMaxLengthConvention was updated in a recent change to improve extensibility, but the SqlCe version of that convention was not similarly updated. The Sql Ce convention should be updated to use a constant that is set from the constructor in a similar manner to the PropertyMaxLengthConvention
Comments: I would be happy to have a stab at implementing this optional constructor

↧

Commented Feature: Make Migrations DB engine independent. [1364]

September 25, 2013, 11:58 pm

≫ Next: Commented Feature: Make Migrations DB engine independent. [1364]

≪ Previous: Commented Issue: UpForGrabs: SqlCePropertyMaxLengthConvention should be updated to reflect changes in the standard PropertyMaxLengthConvention [1322]

As I understand, currently Migrations are dependent on the used Database engine, and don't work, when another engine is used, since the edmx model is checked against a hash of the edmx model used at design time, and the edmx model is not engine independent. Would it be feasible, to check for example for the number of migrations instead of a edmx hash, so the migrations are database independent?
Consider for example a CMS that supports different DB back ends like MySQL or sqlite. At development time one works for example with SQL server and creates all the migrations, but the same migrations should equally work under mysql.

Comments: Hi, Thanx for your comment. Messing around with raw-SQL is of no use. I want to be able to develop my CodeFirst, and just plugin another DB backend as I like, anytime I want without messing around with creating new migrations or with SQL. If I develop a CMS, the CSM should be able to switch to any DB backend that supports EF6, without recompiling the migrations.

↧

Commented Feature: Make Migrations DB engine independent. [1364]

September 26, 2013, 12:01 am

≫ Next: Reviewed: EF 5.0.0 (九月 26, 2013)

≪ Previous: Commented Feature: Make Migrations DB engine independent. [1364]

As I understand, currently Migrations are dependent on the used Database engine, and don't work, when another engine is used, since the edmx model is checked against a hash of the edmx model used at design time, and the edmx model is not engine independent. Would it be feasible, to check for example for the number of migrations instead of a edmx hash, so the migrations are database independent?
Consider for example a CMS that supports different DB back ends like MySQL or sqlite. At development time one works for example with SQL server and creates all the migrations, but the same migrations should equally work under mysql.

Comments: It's also of no use if migrations are DB independent "for the most part", they need to be running on every DB backend without an AutomaticMigrationsDisabledException.

↧

Latest Images