Deleting an entity

145 views
Skip to first unread message

alang...@hotmail.com

unread,
Jul 29, 2013, 10:59:29 PM7/29/13
to brightsta...@googlegroups.com
Hi,

There is very little documentation about deleting an entity.
I have an entity A containing a collection of entities B.
Entity A has an inverse property pointing to a property in entity B.

I have tried two methods for removing an entity B object.

1) Call the DeleteObject method on the context followed by SaveChanges.

This removes the desired entity from the B entity set in the DB, but does not remove it from the A entity set to which it was linked - the fields are set to null but the Id still exists.
This means when I test the count of objects has reduced, it fails.

2) If I explicitly call Remove on the collection of B entities within the A object and then call SaveChanges, the item is removed from the A object in the DB, but still exists in the B entity set in the DB.

How do I remove an object and have it deleted from the related object entirely.

Regards
Alan

Khalil Ahmed

unread,
Jul 30, 2013, 4:12:52 AM7/30/13
to brightsta...@googlegroups.com
Hi Alan,

If I understand you correctly you have entity definitions  that are something like this:

interface IA {
  [InverseProperty("ParentA")]
  ICollection<IB> CollectionOfB {get;set;}
}

interface IB {
  IA ParentA {get;set;}
}

In what you describe it sounds like (2) is behaving as expected/desgined, someA.CollectionOfB.Remove(someB) will just delete the property that connects someB to someA - neither entity will be removed. (1) sounds like it is not behaving correctly - calling context.Delete(someB) should delete someB and all of its properties - including removing someB from any collection that it is in. My guess is what you are seeing is that the local object reference managed by the EntityFramework is not removed from the someA.CollectionOfB property. However, I think that this is probably just an issue in the local context, and if you create a new context and get someA, I think you will find that the collection will be correct.

I have logged this as an issue to take a look at: https://github.com/BrightstarDB/BrightstarDB/issues/27. If you have any further info / clarifications that might help please feel free to add them to that bug or to just reply on this thread.

In the short term I think the work around is to dispose of the context after you have done SaveChanges() and create a new context to access the updated values.

Cheers

Kal




--
You received this message because you are subscribed to the Google Groups "BrightstarDB Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-us...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Kal Ahmed
Director, Networked Planet Limited
e: kal....@networkedplanet.com
w: www.networkedplanet.com

alang...@hotmail.com

unread,
Jul 30, 2013, 4:51:15 PM7/30/13
to brightsta...@googlegroups.com
Hi Kal,

Many thanks for looking into this and logging a bug report.

Your interpretation of the problem is correct. I agree that 2) is probably as designed but it would be useful if this method of deleting an object was also consistent as this provides maximum user flexibility.
I modified my test case and created a new context after performing the DeleteObject. You were correct in your diagnosis, the original context still had 4 entries (of which one contained nulls except for Id) and the newly obtained context only had 3 entries as expected.

I am using the repository pattern to manage the data access and this has a single instance of the context as a private member.
What would be your suggestion for modifying this pattern in the absence of a bug fix - if I did a 'using' in each method would objects be detached from the context.

Regards
Alan
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-users+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Kal Ahmed
Director, Networked Planet Limited
e: kal....@networkedplanet.com
w: www.networkedplanet.com
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-users+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Kal Ahmed
Director, Networked Planet Limited
e: kal....@networkedplanet.com
w: www.networkedplanet.com
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-users+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

alang...@hotmail.com

unread,
Jul 30, 2013, 7:39:57 PM7/30/13
to brightsta...@googlegroups.com
Hi Kal,

As I workaround I'm trying to follow your suggesting of disposing the context by using a Unit Of Work pattern however the EntityContext does not have a Dispose() method.

Regards
Alan

Khalil Ahmed

unread,
Jul 31, 2013, 3:25:20 AM7/31/13
to brightsta...@googlegroups.com
Hi Alan,

I think a Unit Of Work pattern is the way to go - especially for data with regular updates. 

I recently added an implementation of the IDisposable interface to the generated context, but it wasn't in the 1.3 release. Can you try building BrightstarDB from source code ? Although there aren't any instructions it is really as simple as grabbing the source and then building src\core\BrightstarDB.sln. If its a problem let me know and I'll see if I can make an interim release via our CodePlex page.

Cheers

Kal


To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-us...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Khalil Ahmed

unread,
Jul 31, 2013, 5:00:38 AM7/31/13
to brightsta...@googlegroups.com
Hi Alan,

I've just pushed a fix for the entity context. Now if you call context.DeleteObject(foo), the foo object is also removed from the properties of any other locally tracked entities. I still think that in general a Unit of Work approach is better as it prevents your list of locally tracked entities getting too large and affecting performance (though as it is all in-memory, there would have to be quite a lot of locally tracked objects for this to really impact).

If you get a chance to try it out for yourself and let me know if it fixes the problem that would be much appreciated.

Cheers

Kal

alang...@hotmail.com

unread,
Jul 31, 2013, 5:59:59 PM7/31/13
to brightsta...@googlegroups.com
Hi Kal,

I downloaded the source and built it using VS2012. I had to get a copy of the MSBuild Community Tasks in order to get the projects to load. I also had to update the path to the NUnit dll.
All projects built except for a couple of the test ones

Type or namespace 'TextContext' could not be found (BrightstarDB.Tests -> StringComparisonTests.cs)
Type or namespace 'DescriptionAttribute' does not exist in the namespace NUnit.Framework (BrightstarDB.Tests -> SimpleContextTests.cs)

I updated my working solution with the revised BrightstarDB libraries and the DeleteObject problem is now fixed.
I do keep having problems with my test class though whereby tests fail with a 'Store already exists' error.

My tests are structured with a test initializer that creates the context and a test cleanup that calls BrightstarService.GetClient().DeleteStore(storename). These happen before/after each test. It appears the store is not getting deleted properly.

I have the context within a repository class so I can expose some useful methods to my application and also mock the repository. I tried using a unit of work pattern with this but could not see how I would use this inside a WPF ViewModel (and more importantly be able to mock it or use dependency injection). I felt the UoW wasn't really offering anything.

Regards
Alan
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-users+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-users+unsubscribe@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Kal Ahmed
Director, Networked Planet Limited
e: kal....@networkedplanet.com
w: www.networkedplanet.com

--
You received this message because you are subscribed to the Google Groups "BrightstarDB Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-users+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 



--
Kal Ahmed
Director, Networked Planet Limited

alang...@hotmail.com

unread,
Jul 31, 2013, 6:10:42 PM7/31/13
to brightsta...@googlegroups.com
Hi Kal,

I just debugged through the DeleteStore and I am getting an exception 'The process cannot access the file 'data.bs' because it is being used by another process." This is thrown from line 168 of BPlusTreeStoreManager.cs where the attempt to delete the directory is made. Hope this helps.

Regards
Alan

Khalil Ahmed

unread,
Aug 1, 2013, 6:56:07 AM8/1/13
to brightsta...@googlegroups.com
Hi Alan,

Thanks for the heads-up on the NUnit issue - I've updated the projects to use the NUnit NuGet package so hopefully that should be fixed for future users!

I think you are seeing this problem because the unit test runner will run multiple tests in parallel, which means that you will end up with the tests treading on each others toes when trying to clean up the store.

In my unit tests I tend to use a separate store for each test and manage the store within the test. Typically I don't delete the store, instead I use a unique store name for each run - either by using a GUID or more recently I have taken to having a base name for the store and then appending DateTime.Now.Ticks.ToString() to the end so that it is easier for me to see which tests created which stores. The down side is that every test run is going to add more stores, but the upside is that when a test fails you can get in there with Polaris and see if the RDF data in the store matches what you expect (or why it doesn't!).

Depending on your unit tests you may want to either use that pattern or else move your store creation and cleanup into the TestFixtureSetUp and TestFixtureTearDown stages.

Cheers

Kal


To unsubscribe from this group and stop receiving emails from it, send an email to brightstardb-us...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 
Reply all
Reply to author
Forward
0 new messages