Edited Issue: Memory leak in case of usage an external connection [1805]

November 15, 2013, 4:03 pm

≫ Next: Commented Issue: Memory leak in case of usage an external connection [1805]

≪ Previous: Edited Issue: Code First: TPC with joins from base class to Identity ApplicationUser Fails [1791]

$

0

0

EF6 has a memory leak in some specific situations. Please look at following code.

```
using (var connection = new SqlConnection(connectionString))
{
connection.Open();

using (var transaction = connection.BeginTransaction())
{
// need to use a lot of small updates instead of one update, because the count of affected records is very big and MemoryOverflow exception can be thrown
for (int i = 0; i < 100; i++)
{
using (var context = new DbContext(connection, false))
{
context.Database.UseTransaction(transaction);

// some updates and inserts

context.SaveChanges();

context.Database.UseTransaction(null);
}

// there is a memory leak.
// all disposed context are stayed in the memory
// the cause of this behavior is attached event handler for the event StateChange on connection
}

transaction.Commit();
}
}

```

If DbContext is created with external connection, then such context will not be disposed, because EntityConnection attached an event handler to the StateChange event in the external connection and this handler is not detached during disposing of DbContext. Therefore GC cannot collect this instance of context.

I use following workaround for this situation.

```
private static void ContextDisposingWorkaround(DbContext context)
{
var connection = context.Database.Connection;
var objectContext = ((IObjectContextAdapter) saveContext).ObjectContext;

ReflectionHelper.RemoveEventHandlers(typeof (DbConnection), "StateChange", "_stateChangeEventHandler", connection,
objectContext.Connection);
}
```
Need to call above method before disposing of context.

---

Commented Issue: Memory leak in case of usage an external connection [1805]

November 15, 2013, 4:03 pm

≫ Next: Edited Issue: Code First: setting max length and type to "nvarchar" at same time has unexpected results [1784]

≪ Previous: Edited Issue: Memory leak in case of usage an external connection [1805]

$

0

0

EF6 has a memory leak in some specific situations. Please look at following code.

```
using (var connection = new SqlConnection(connectionString))
{
connection.Open();

using (var transaction = connection.BeginTransaction())
{
// need to use a lot of small updates instead of one update, because the count of affected records is very big and MemoryOverflow exception can be thrown
for (int i = 0; i < 100; i++)
{
using (var context = new DbContext(connection, false))
{
context.Database.UseTransaction(transaction);

// some updates and inserts

context.SaveChanges();

context.Database.UseTransaction(null);
}

// there is a memory leak.
// all disposed context are stayed in the memory
// the cause of this behavior is attached event handler for the event StateChange on connection
}

transaction.Commit();
}
}

```

If DbContext is created with external connection, then such context will not be disposed, because EntityConnection attached an event handler to the StateChange event in the external connection and this handler is not detached during disposing of DbContext. Therefore GC cannot collect this instance of context.

I use following workaround for this situation.

```
private static void ContextDisposingWorkaround(DbContext context)
{
var connection = context.Database.Connection;
var objectContext = ((IObjectContextAdapter) saveContext).ObjectContext;

ReflectionHelper.RemoveEventHandlers(typeof (DbConnection), "StateChange", "_stateChangeEventHandler", connection,
objectContext.Connection);
}
```
Need to call above method before disposing of context.
Comments: Fixed with #8af8e25. ObjectContext was not calling Dispose() on its EntityConnection because DbCompiledModel (which was creating both of them) was not telling ObjectContext that it owned the EntityConnection. Updated so it did tell it that plus needed to update the EntityConnection Dispose() which was assuming that if it was being disposed then it should close the underlying store connection regardless of whether it "owned" that connection. Fix all that and added a test to check that the event subscription no longer exists once the context (and hence it's EntityConnection) have been disposed.

Edited Issue: Code First: setting max length and type to "nvarchar" at same time has unexpected results [1784]

November 15, 2013, 5:05 pm

≫ Next: New Post: EF6 runtime DbContext/ObjectContext supports MEST?

≪ Previous: Commented Issue: Memory leak in case of usage an external connection [1805]

$

0

0

This issue resulted from investigation of https://entityframework.codeplex.com/workitem/1771. The issues are probably related.

This is about the interaction between partially specified column types and max length settings for string properties. By partially specified column types I mean using just “nvarchar” rather than “nvarchar(x)” where x is max, 4000, etc.

There are regressions from EF5 here.

The interesting lines are bolded below. (Also see triage decisions in the comment below)

__EF5/SQL Server:__

Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct

Column type set to “nvarchar(max)” and no max length
* Same as above

Column type set to “nvarchar(1234)” and any max length
* __Throws: “The Type nvarchar(1234) is not qualified with a namespace or alias.”__
* Interesting that nvarchar(max) is allowed but nvarchar(1234) is not

Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" Nullable="true"
- Correct
* Database
- nvarchar(128)
- __Could be considered correct if 128 is considered the default value in this case__

Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- __Correct, but interestingly different__
* Database
- nvarchar(1234)
- Correct

Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __Throws from differ after model creation: “Unhandled Exception: System.FormatException: Input string was not in a correct format.”__
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different
* Database
- Throws


__EF6/SQL Server:__

Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar(max)" Nullable="true"
- Correct
* Database
- nvarchar(max)
- Correct

Column type set to “nvarchar(max)” and no max length
* Same as above

Column type set to “nvarchar(1234)” and any max length
* __Throws: “System.InvalidOperationException: Sequence contains no matching element”__
* The exception is not good, but is thrown for the same reason as the EF5 exception
* __Will file a new bug for this; do not fix as part of this bug.__

Column type set to “nvarchar” and no max length
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="Max" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- __Could be considered correct, but different from EF5 behavior__
* Database
- nvarchar(4000)
- __Again, could be considered correct, but different from EF5__
- __As described in the comments section, this seems like the correct behavior and we will keep it going forward.__

Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5
* Database
- nvarchar(1234)
- Correct

Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* __No exception in EF6__
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct, but also interestingly different as in EF5
* Database
- nvarchar(128)
- __Wrong, but matches EF5 case with nvarchar and no max length__
- __See comments below: this should be fixed to generate nvarchar(4000)__

__EF6/SQL Compact:__

Column type not set and no max length (i.e. the default):
* CSDL
- Name="Description" Type="String" MaxLength="4000" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="4000" Nullable="true"
- As expected for SQL CE due to max length convention

Column type set to “nvarchar” and no max length
* Same as above

Anything that sets column type set to “nvarchar(max)” or “nvarchar(1234)”
* Throws: “System.InvalidOperationException: Sequence contains no matching element”
* This is the same as SQL Server for nvarchar(1234) but SQL Compact also doesn’t support nvarchar(max) as a type

Column type set to “nvarchar” and max length set to 1234
* CSDL
- Name="Description" Type="String" FixedLength="false" MaxLength="1234" Unicode="true" Nullable="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="1234" Nullable="true"
- Correct, but interestingly different as in EF5

Column type set to “nvarchar” and IsMaxLength or MaxLength(-1)/MaxLength attribute
* CSDL
- Name="Description" Type="String" MaxLength="Max" FixedLength="false" Unicode="true"
- Correct
* SSDL
- Name="Description" Type="nvarchar" MaxLength="Max" Nullable="true"
- Correct

New Post: EF6 runtime DbContext/ObjectContext supports MEST?

November 15, 2013, 6:48 pm

≫ Next: Commented Unassigned: EF 6.1 Foreignkey bug [1833]

≪ Previous: Edited Issue: Code First: setting max length and type to "nvarchar" at same time has unexpected results [1784]

$

0

0

Hi Diego.

I checked the new version 1763ddb2f4f8.

It works well.
I can get SchemaInformation from both System.Data.SqlClient and Npgsql providers!

Sorry for taking so much time to verify your fix. I had trouble with EF relationship.

I knew:

• ObjectContext.CreateQuery won't solve relationship.
• ObjectContext.CreateObjectSet will solve relationship.
  

I'm using mapping view generated by EdmGen in .NET3.5. It uses CreateQuery for tables.
I noticed EdmGen in .NET4.5 uses CreateObjectSet.

I'll use CreateObjectSet, and it works well :)

thanks
kenji uno

Commented Unassigned: EF 6.1 Foreignkey bug [1833]

November 15, 2013, 8:02 pm

≫ Next: New Post: load master and refresh details,how to?

≪ Previous: New Post: EF6 runtime DbContext/ObjectContext supports MEST?

$

0

0

The following is the code of IsPrincipalEndOfReferentialConstraint method of System.Data.Entity.Core.Objects.DataClasses.RelatedEnd:

```
internal bool IsPrincipalEndOfReferentialConstraint()
{
if (this._relationMetadata != null)
{
foreach (ReferentialConstraint constraint in ((AssociationType) this._relationMetadata).ReferentialConstraints)
{
if (constraint.FromRole == this._fromEndMember)
{
return CheckIfAllPropertiesAreKeyProperties(constraint.ToRole.GetEntityType().KeyMemberNames, constraint.ToProperties);
}
}
}
return false;
}
```
__The second parameter passed to CheckIfAllPropertiesAreKeyProperties must be constraint.FromProperties not constraint.ToProperties.__

Use constraint.ToProperties will cause a bug if the two ends of foreignkey use different names, for example, there are two tables, SalesOrder(Id, SONumber) and SalesOrderDetail(Id, SalesOrderId not null, ProductName), SalesOrderId is a foreign key reference Id column of SalesOrder table. The following pseudo code will cause save method of dbcontext to throw an exception:
var salesOrder = dbContext.SalesOrder.First();
var salesOrderDetail = salesOrder.SalesOrder.Detail.First();
salesOrder.SalesOrderDetail.Remove(salesOrderDetail);
The state of the removed salesOrderDetail is EntityState.Modified not EntityState.Deleted. Because EF 6.1 used constraint.ToProperties not constraint.FromProperties, the CheckIfAllPropertiesAreKeyProperties returns false, not true, the removed salesOrderDetail will not be marked as deleted.



Comments: The IsDependentEndOfReferentialConstraint method of RelatedEnd also used constraint.ToProperties. ``` internal bool IsDependentEndOfReferentialConstraint(bool checkIdentifying) { if (this._relationMetadata != null) { foreach (ReferentialConstraint constraint in ((AssociationType) this.RelationMetadata).ReferentialConstraints) { if (constraint.ToRole == this.FromEndMember) { if (checkIdentifying) { return CheckIfAllPropertiesAreKeyProperties(constraint.ToRole.GetEntityType().KeyMemberNames, constraint.ToProperties); } return true; } } } return false; } ```

New Post: load master and refresh details,how to?

November 15, 2013, 10:21 pm

≫ Next: Commented Unassigned: EF 6.1 Foreignkey bug [1833]

≪ Previous: Commented Unassigned: EF 6.1 Foreignkey bug [1833]

$

0

0

table a,table b
first a.load();
then find a with include "b"

here i update b with sql in sqlserver managerment
if I use objectContext.Refresh(RefreshMode.StoreWins, b.Local); I can get the new b items with a;

I use the generic repository,in my find fuction my code like :

           var query = ctx.Set<T>().Where(t => true);
            foreach (string include in includes)
            {
                query = query.Include(include);
                query.Load();
            }
            query.Load();
            result.Entities = query.Where(filter.Compile());

always not refresh the b object from database.

Commented Unassigned: EF 6.1 Foreignkey bug [1833]

November 15, 2013, 10:59 pm

≫ Next: New Post: Spatial DataReader and Wrapping Providers in EF6

≪ Previous: New Post: load master and refresh details,how to?

$

0

0

The following is the code of IsPrincipalEndOfReferentialConstraint method of System.Data.Entity.Core.Objects.DataClasses.RelatedEnd:

```
internal bool IsPrincipalEndOfReferentialConstraint()
{
if (this._relationMetadata != null)
{
foreach (ReferentialConstraint constraint in ((AssociationType) this._relationMetadata).ReferentialConstraints)
{
if (constraint.FromRole == this._fromEndMember)
{
return CheckIfAllPropertiesAreKeyProperties(constraint.ToRole.GetEntityType().KeyMemberNames, constraint.ToProperties);
}
}
}
return false;
}
```
__The second parameter passed to CheckIfAllPropertiesAreKeyProperties must be constraint.FromProperties not constraint.ToProperties.__

Use constraint.ToProperties will cause a bug if the two ends of foreignkey use different names, for example, there are two tables, SalesOrder(Id, SONumber) and SalesOrderDetail(Id, SalesOrderId not null, ProductName), SalesOrderId is a foreign key reference Id column of SalesOrder table. The following pseudo code will cause save method of dbcontext to throw an exception:
var salesOrder = dbContext.SalesOrder.First();
var salesOrderDetail = salesOrder.SalesOrder.Detail.First();
salesOrder.SalesOrderDetail.Remove(salesOrderDetail);
The state of the removed salesOrderDetail is EntityState.Modified not EntityState.Deleted. Because EF 6.1 used constraint.ToProperties not constraint.FromProperties, the CheckIfAllPropertiesAreKeyProperties returns false, not true, the removed salesOrderDetail will not be marked as deleted.



Comments: I think the code of IsDependentEndOfReferentialConstraint method should be as follows: ``` internal bool IsDependentEndOfReferentialConstraint(bool checkIdentifying) { if (this._relationMetadata != null) { foreach (ReferentialConstraint constraint in ((AssociationType) this.RelationMetadata).ReferentialConstraints) { if (constraint.ToRole == ___toEndMember__) { if (checkIdentifying) { return CheckIfAllPropertiesAreKeyProperties(constraint.ToRole.GetEntityType().KeyMemberNames, constraint.__FromProperties__); } return true; } } } return false; } ```

New Post: Spatial DataReader and Wrapping Providers in EF6

November 17, 2013, 2:01 pm

≫ Next: Created Unassigned: Actually use MigrationOperation.AnonymousArguments to do...things... [1840]

≪ Previous: Commented Unassigned: EF 6.1 Foreignkey bug [1833]

$

0

0

Model

public class TestEF6DataSource : DbContext
{
    public DbSet<MattShape> MattShapes { get; set; }
}

public class MattShape
{
    [Key]
    public int MattShapeId { get; set; }

    [Required]
    public DbGeometry GeoShape { get; set; }
}

Migrations

public sealed class Configuration : DbMigrationsConfiguration<TestEF6DataSource>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = true;
    }

    protected override void Seed(TestEF6DataSource context)
    {
    context.MattShapes.AddOrUpdate(
        m => m.MattShapeId,
        new MattShape { MattShapeId = 1, GeoShape = DbGeometry.FromText("POLYGON ((1843503.54576196 5743170.10983084, 1843627.97736856 5743384.66544795, 1843557.59765677 5743393.36080548, 1843362.48753989 5743417.46230251, 1843361.11361057 5743417.63180584, 1843358.43835504 5743418.34609364, 1843355.88774656 5743419.42171531, 1843353.50983276 5743420.83971631, 1843352.42925232 5743421.70492403, 1843051.20263201 5743663.02873092, 1843050.40246141 5743663.67014246, 1843048.94101245 5743665.10920791, 1843047.63448048 5743666.69052689, 1843046.49589101 5743668.39810608, 1843045.53827419 5743670.21195005, 1843044.77165509 5743672.11506149, 1843044.20306302 5743674.085437, 1843043.83952263 5743676.10507526, 1843043.76129276 5743677.12752066, 1843043.68306289 5743678.14996605, 1843043.73770804 5743680.20110406, 1843044.00148376 5743682.23547495, 1843044.47141291 5743684.23206429, 1843045.14351779 5743686.16985646, 1843046.01081798 5743688.02883293, 1843047.06232975 5743689.78997102, 1843048.28907043 5743691.4342504, 1843048.98356169 5743692.18944876, 1843227.79751488 5743886.66320856, 1843370.49789926 5744041.86289133, 1843211.63121968 5744181.85544627, 1843210.88004919 5744182.51692323, 1843209.51761462 5744183.9841149, 1843208.30811202 5744185.57955102, 1843207.26456693 5744187.28723829, 1843206.3960028 5744189.09117878, 1843205.7124471 5744190.97237412, 1843205.219924 5744192.91282186, 1843204.92345948 5744194.89251733, 1843204.87426871 5744195.89198485, 1843204.82507793 5744196.89145237, 1843204.92780195 5744198.89162105, 1843205.22865675 5744200.87000785, 1843205.72666166 5744202.80960272, 1843206.41483744 5744204.68938653, 1843207.28720192 5744206.49134292, 1843208.33477247 5744208.1964515, 1843209.548563 5744209.78869344, 1843210.23107302 5744210.52086848, 1843362.82471731 5744374.04062576, 1843521.47199211 5744544.04810409, 1843522.80403726 5744545.4754015, 1843525.96805836 5744547.76127718, 1843529.51504843 5744549.39225262, 1843533.31000687 5744550.30713888, 1843537.21089892 5744550.47075254, 1843541.06965155 5744549.87791897, 1843544.74116062 5744548.55148175, 1843548.0862959 5744546.53930455, 1843549.53359801 5744545.22929443, 1844144.05575353 5744006.88500424, 1844169.18539025 5743983.5857433, 1844170.63172801 5743982.24570703, 1844172.94368956 5743979.05168963, 1844174.58874644 5743975.46769333, 1844175.50270343 5743971.63171704, 1844175.57703662 5743969.66175839, 1844175.90023907 5743961.04656371, 1844175.97457214 5743959.07660504, 1844175.5375125 5743956.34865246, 1844175.73760702 5743956.35989003, 1844177.73678424 5743956.27215751, 1844179.71618148 5743955.98629701, 1844181.65778673 5743955.50428874, 1844183.54258396 5743954.83111332, 1844185.34955492 5743953.97274958, 1844187.06267936 5743952.93918428, 1844188.66293657 5743951.73940016, 1844189.4001205 5743951.0628946, 1844199.50135086 5743941.78666567, 1844213.84039117 5743928.61827538, 1844215.28972002 5743927.28724656, 1844217.61466838 5743924.11025168, 1844219.27671508 5743920.54228211, 1844219.35211419 5743920.23420591, 1844219.64432342 5743920.18952037, 1844223.35289272 5743918.83709466, 1844226.72609487 5743916.78591001, 1844228.17943055 5743915.45088351, 1844242.51647028 5743902.28248667, 1844253.4640615 5743892.22881894, 1844254.21126251 5743891.54231917, 1844255.55975269 5743890.02607475, 1844256.74730665 5743888.38057548, 1844257.7628975 5743886.62381815, 1844258.59449784 5743884.7737984, 1844259.23508291 5743882.84851766, 1844259.67862504 5743880.86898012, 1844259.91909887 5743878.85418888, 1844259.93628859 5743877.83967025, 1844259.97595609 5743875.56550898, 1844263.40172796 5743875.62750567, 1844265.30771411 5743875.66172916, 1844269.06349335 5743875.01072919, 1844272.62898191 5743873.66213868, 1844275.87505338 5743871.66483413, 1844277.28130799 5743870.37777789, 1844293.26093854 5743855.74349582, 1844293.42794675 5743855.81372633, 1844297.16404668 5743856.59746499, 1844300.98202765 5743856.66191644, 1844304.74282077 5743856.00191699, 1844308.31032266 5743854.64332287, 1844311.55740795 5743852.63501293, 1844312.96166863 5743851.34195079, 1844366.48183378 5743802.05767893, 1844367.94418863 5743800.71065451, 1844370.28118872 5743797.49464845, 1844371.94128574 5743793.88164838, 1844372.85727827 5743790.01365209, 1844372.92562613 5743788.02667511, 1844372.99397396 5743786.03969812, 1844372.34618617 5743782.11786455, 1844370.93975308 5743778.39926161, 1844368.82953432 5743775.03003047, 1844367.46347793 5743773.58568301, 1844311.37120972 5743714.28931765, 1844598.56152946 5743510.53102903, 1844599.82925634 5743509.63101582, 1844602.05797441 5743507.46143768, 1844603.92386625 5743504.97427061, 1844605.3828408 5743502.22749453, 1844606.40080074 5743499.28910624, 1844606.95165187 5743496.22811234, 1844607.02330055 5743493.11953884, 1844606.61466136 5743490.03642345, 1844606.1741564 5743488.54511938, 1844558.82589522 5743328.15393844, 1844545.72733704 5743226.88587176, 1844545.50322096 5743225.15769254, 1844544.46552075 5743221.83172273, 1844542.86925421 5743218.73523003, 1844540.76133973 5743215.96031771, 1844539.4830261 5743214.77621074, 1844471.09777847 5743151.40250573, 1844439.20618072 5743078.48089337, 1844438.77908038 5743077.50588234, 1844437.72365546 5743075.65568148, 1844436.47798437 5743073.92932726, 1844435.05605492 5743072.34384485, 1844433.47485308 5743070.9192645, 1844431.75037123 5743069.6696121, 1844429.90260273 5743068.60991869, 1844427.95354434 5743067.75321654, 1844426.93937208 5743067.42987565, 1844347.35981 5743042.11069952, 1844087.70346261 5742812.08654871, 1844086.51504258 5742811.03362263, 1844083.8365753 5742809.32963639, 1844080.92346809 5742808.06961547, 1844077.84672431 5742807.28365755, 1844074.68536083 5742806.99386527, 1844071.51841542 5742807.20433173, 1844068.42393221 5742807.91314573, 1844065.47897565 5742809.10038539, 1844064.11929846 5742809.91825389, 1843510.54101528 5743142.92357374, 1843508.86995706 5743143.92917723, 1843505.97737608 5743146.54822255, 1843503.64650513 5743149.67618338, 1843501.9625264 5743153.19509576, 1843500.99062767 5743156.97296537, 1843500.76599237 5743160.86775796, 1843501.29879528 5743164.7334084, 1843502.56719526 5743168.42281405, 1843503.54576196 5743170.10983084))") },
        new MattShape { MattShapeId = 2, GeoShape = DbGeometry.FromText("POLYGON ((1767189.79377487 5904558.30070561, 1767215.1492355 5904492.43152391, 1767215.22475214 5904445.62448443, 1767192.95192382 5904443.13290794, 1767196.09833442 5904422.95242129, 1767174.81164464 5904414.75687878, 1767129.42429366 5904534.9388636, 1767189.79377487 5904558.30070561))") }
        );

        context.SaveChanges();
    }
}

Wrappers

public class TestDbProviderServices : DbProviderServices
{
    private DbProviderServices InnerProviderServices { get; set; }

    public TestDbProviderServices(DbProviderServices inner)
    {
        InnerProviderServices = inner;
    }

    protected override DbCommandDefinition CreateDbCommandDefinition(DbProviderManifest providerManifest, DbCommandTree commandTree)
    {
        return InnerProviderServices.CreateCommandDefinition(providerManifest, commandTree);
    }

    protected override string GetDbProviderManifestToken(DbConnection connection)
    {
        return InnerProviderServices.GetProviderManifestToken(connection);
    }

    protected override DbProviderManifest GetDbProviderManifest(string manifestToken)
    {
        return InnerProviderServices.GetProviderManifest(manifestToken);
    }

    protected override DbSpatialDataReader GetDbSpatialDataReader(DbDataReader fromReader, string manifestToken)
    {
        return InnerProviderServices.GetSpatialDataReader(fromReader, manifestToken);
    }
}

public class TestDbConnectionFactory : IDbConnectionFactory
{
    private IDbConnectionFactory InnerDbConnectionFactory { get; set; }

    public TestDbConnectionFactory(IDbConnectionFactory inner)
    {
        InnerDbConnectionFactory = inner;
    }

    public DbConnection CreateConnection(string nameOrConnectionString)
    {
        return InnerDbConnectionFactory.CreateConnection(nameOrConnectionString);
    }
}

Test Console App

class Program
{
    static void Main(string[] args)
    {
        DbConfiguration.Loaded += (_, a) =>
        {
            a.ReplaceService<DbProviderServices>((s, k) => new TestDbProviderServices(s));
            a.ReplaceService<IDbConnectionFactory>((s, k) => new TestDbConnectionFactory(s));
        };

        var db = new TestEF6DataSource();
        var point = CreatePoint(1843503.54576196, 5743170.10983084);
        var shapes = db.MattShapes.Where(s => s.GeoShape.Intersects(point)).Select(s => s.MattShapeId).ToList();

        foreach (var shape in shapes)
        {
            System.Console.WriteLine(shape);
        }

        System.Console.ReadKey();
    }

    private static DbGeometry CreatePoint(double x, double y)
    {
        var text = string.Format(CultureInfo.InvariantCulture.NumberFormat, "POINT({0} {1})", x, y);
        return DbGeometry.PointFromText(text, 0);
    }
}

---

Created Unassigned: Actually use MigrationOperation.AnonymousArguments to do...things... [1840]

November 17, 2013, 7:25 pm

≫ Next: Commented Feature: Provide better support for working with disconnected entities [864]

≪ Previous: New Post: Spatial DataReader and Wrapping Providers in EF6

$

0

0

In a custom migration I was attempting to use the form of `DbMigration.Sql()` that takes an anonymous object to pass parameters for a paramterized query. [The documentation implies that this is the way it's meant to work but provides no full examples](http://msdn.microsoft.com/en-us/library/system.data.entity.migrations.dbmigration.sql(v=vs.113).aspx), and no matter what I tried I could not get it to work.

[See the confusion that ensued on Stackoverflow](http://stackoverflow.com/questions/20034612/how-to-pass-parameters-to-dbmigration-sql-method/20035646?noredirect=1#20035646)

So I dug into the source code, and track the argument back to `MigrationOperation.AnonymousArguments` which seems to be used ... only in some unit tests.

So what's going on? Is this argument used at all? If not can it, and the misleading for of the `Sql(... ... ...)` method be removed?

Commented Feature: Provide better support for working with disconnected entities [864]

November 17, 2013, 9:09 pm

≫ Next: Edited Issue: Migrating from EF5 to EF6: InversePropertyAttribute broken? [1792]

≪ Previous: Created Unassigned: Actually use MigrationOperation.AnonymousArguments to do...things... [1840]

$

0

0

This item is to track adding better support for change tracking with graphs of disconnected entities. For more information see this discussion:

"Merge Disconnected Object Graph"
http://entityframework.codeplex.com/discussions/432661

And this user voice item:

"Merge method: automatic synchronization of relationships on a disconnected entity"
http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/1069431-merge-method-automatic-synchronization-of-relation

Comments: I think another approach is better than the one here. Instead of sending the entire modified object graph over the wire, why not instead just send the delta? You wouldn't even need generated DTO classes in that case. If you have an opinion about this either way, please let's discuss is at http://stackoverflow.com/questions/1344066/calculate-object-delta .

Edited Issue: Migrating from EF5 to EF6: InversePropertyAttribute broken? [1792]

November 17, 2013, 9:33 pm

≫ Next: Commented Issue: Migrating from EF5 to EF6: InversePropertyAttribute broken? [1792]

≪ Previous: Commented Feature: Provide better support for working with disconnected entities [864]

$

0

0

This has been reported on [stackoverflow](http://stackoverflow.com/questions/19778324/migrating-from-ef5-to-ef6-inversepropertyattribute-broken) as a regression from EF5.

Commented Issue: Migrating from EF5 to EF6: InversePropertyAttribute broken? [1792]

November 17, 2013, 9:33 pm

≫ Next: Edited Issue: Perf: Revert buffering by default [1819]

≪ Previous: Edited Issue: Migrating from EF5 to EF6: InversePropertyAttribute broken? [1792]

$

0

0

This has been reported on [stackoverflow](http://stackoverflow.com/questions/19778324/migrating-from-ef5-to-ef6-inversepropertyattribute-broken) as a regression from EF5.
Comments: Fixed in changeset 901c80f177f188e6fb32f93e9cc6409aa3bbfdcb

Edited Issue: Perf: Revert buffering by default [1819]

November 17, 2013, 10:16 pm

≫ Next: Commented Issue: Perf: Revert buffering by default [1819]

≪ Previous: Commented Issue: Migrating from EF5 to EF6: InversePropertyAttribute broken? [1792]

$

0

0

Related to #1786 and possibly #1781, the change to buffering is being more impactful than we initially thought it would be. Testing against the provided repros yields performance degradation of 103% and 36% respectively.

We now think the best thing to do is to revert back to streaming by default. In particular:

1) Change default query execution back to streaming. But,
2) Use buffering if the current IDbExecutionStrategy retries on failure.
3) Deprecate the AsStreaming() extension method.

Commented Issue: Perf: Revert buffering by default [1819]

November 17, 2013, 10:16 pm

≫ Next: New Post: Multi-tenancy and connection pool

≪ Previous: Edited Issue: Perf: Revert buffering by default [1819]

$

0

0

Related to #1786 and possibly #1781, the change to buffering is being more impactful than we initially thought it would be. Testing against the provided repros yields performance degradation of 103% and 36% respectively.

We now think the best thing to do is to revert back to streaming by default. In particular:

1) Change default query execution back to streaming. But,
2) Use buffering if the current IDbExecutionStrategy retries on failure.
3) Deprecate the AsStreaming() extension method.

Comments: Fixed in changeset 60340c753215896bc2a6cc2a98cc813979af25c2

New Post: Multi-tenancy and connection pool

November 18, 2013, 3:46 am

≫ Next: New Post: Multi-tenancy and connection pool

≪ Previous: Commented Issue: Perf: Revert buffering by default [1819]

$

0

0

Exposing the baseConnection.StateChange events in XDConnection might help to resolve the "The connection is not open." exception thrown on SaveChanges, e.g.:

public override event StateChangeEventHandler StateChange {
    add {
        this._baseConnection.StateChange += value;
    }
    remove {
        this._baseConnection.StateChange -= value;
    }
}

---

New Post: Multi-tenancy and connection pool

November 18, 2013, 4:48 am

≫ Next: New Post: EF 6, Self-Tracking Entities

≪ Previous: New Post: Multi-tenancy and connection pool

$

0

0

@snowgon - this was indeed the problem here - it was resolved here

New Post: EF 6, Self-Tracking Entities

November 18, 2013, 5:24 am

≫ Next: New Post: What UseLegacyProvider=True means

≪ Previous: New Post: Multi-tenancy and connection pool

$

0

0

FYI, I authored Trackable Entities as a replacement for STE's: https://trackable.codeplex.com. It's deployed as a set of NuGet packages and Visual Studio extensions. There are a set of project templates, with T4 templates for ASP.NET Web API scaffolding, as well as item templates for generating WCF services.

Here is a blog post I wrote comparing TE's with STE's: http://blog.tonysneed.com/2013/11/18/trackable-entities-versus-self-tracking-entities.

Cheers,
Tony

New Post: What UseLegacyProvider=True means

November 18, 2013, 5:42 am

≫ Next: Commented Issue: Memory leak in case of usage an external connection [1805]

≪ Previous: New Post: EF 6, Self-Tracking Entities

$

0

0

I switched my project to Entity Framework v6. When I Updated Model from Database, EF Designer included this element in EDMX:

<DesignerProperty Name="UseLegacyProvider" Value="True" />

What it means? And why is it True?

Commented Issue: Memory leak in case of usage an external connection [1805]

November 18, 2013, 6:17 am

≫ Next: Commented Unassigned: Version 6.0.2-nightly-21113 DbEntityValidationException without detail [1835]

≪ Previous: New Post: What UseLegacyProvider=True means

$

0

0

EF6 has a memory leak in some specific situations. Please look at following code.

```
using (var connection = new SqlConnection(connectionString))
{
connection.Open();

using (var transaction = connection.BeginTransaction())
{
// need to use a lot of small updates instead of one update, because the count of affected records is very big and MemoryOverflow exception can be thrown
for (int i = 0; i < 100; i++)
{
using (var context = new DbContext(connection, false))
{
context.Database.UseTransaction(transaction);

// some updates and inserts

context.SaveChanges();

context.Database.UseTransaction(null);
}

// there is a memory leak.
// all disposed context are stayed in the memory
// the cause of this behavior is attached event handler for the event StateChange on connection
}

transaction.Commit();
}
}

```

If DbContext is created with external connection, then such context will not be disposed, because EntityConnection attached an event handler to the StateChange event in the external connection and this handler is not detached during disposing of DbContext. Therefore GC cannot collect this instance of context.

I use following workaround for this situation.

```
private static void ContextDisposingWorkaround(DbContext context)
{
var connection = context.Database.Connection;
var objectContext = ((IObjectContextAdapter) saveContext).ObjectContext;

ReflectionHelper.RemoveEventHandlers(typeof (DbConnection), "StateChange", "_stateChangeEventHandler", connection,
objectContext.Connection);
}
```
Need to call above method before disposing of context.
Comments: I just tested 6.0.2-nightly-21117 and it hasn't fixed the issue. If I explicitly dispose the EntityConnection that was passed into the DbContext constructor after disposing the context itself, ie: var entityConnection = ((IObjectContextAdapter)dbContext).ObjectContext.Connection; dbContext.Dispose(); entityConnection.Dispose(); Then the memory is freed. If i skip the entityConnection.Dipose() then it is not, and the memory usage grows as each new dbConext is constructed.

Commented Unassigned: Version 6.0.2-nightly-21113 DbEntityValidationException without detail [1835]

November 18, 2013, 6:40 am

≫ Next: Created Unassigned: Use Fully Qualified Names [1844]

≪ Previous: Commented Issue: Memory leak in case of usage an external connection [1805]

$

0

0

With Version 6.0.2-nightly-21113
Calling SaveChanges() returned DbEntityValidationException but detail not provided. see attached image

{System.Data.Entity.Validation.DbEntityValidationResult}

public override int SaveChanges()
{
try
{
base.SaveChanges();

}
catch (DbEntityValidationException)
{
throw;
}
}
Comments: The issue is not specific to 6.0.2 and also occurs in EF5. A property of an entity has an attribute of IsRequired() in a map file but a value is not provided and a null is passed when the entity is to be persisted. A DbEntityValidationException is thrown but detail is not provided.