Why UnitOfWork.Attach disables deleting of objects from database

I try to delete objects from database. Let's assume we DBItem and DBSubItem with strong (not nullable) one-to-many relation. Then we have the code:

         // Load Items and SubItems

         EntityCollection<DBItem> Items = new EntityCollection<DBItem>();

         EntityCollection<DBSubItem> SubItems = new EntityCollection<DBSubItem>();

         using (var uow = _context.CreateUnitOfWork())

         {

            Items.AddRange(uow.DBItems);

            SubItems.AddRange(uow.DBSubItems);

         }

         // Delete Items, subitems should be deleted automatically

         using (var uow = _context.CreateUnitOfWork())

         {

            // ====== That's the code, I have doubts about =======

            foreach (var item in Items)

               uow.Attach(item);

            foreach (var subItem in SubItems)

               uow.Attach(subItem);

            // ===================================================

            List<DBItem> tmp = new List<DBItem>(Items);

            foreach (var item in tmp)

               uow.Remove(item);

            uow.SaveChanges();

         }

         // Check the result

         int itemsCount, subItemsCount;

         using (var uow = _context.CreateUnitOfWork())

         {

            itemsCount = uow.DBItems.Count();

            subItemsCount = uow.DBSubItems.Count();

         }

I purposely put all the fragments into separate UnitOfWork, because they exist in different methods in the real code.

Running such code on not empty database (DBItems and DBSubItems tables are not empty) results with nothing deleted! When I remove the code within '=======' comment, everything works fine.

Honestly speaking I expected just the opposite behaviour - when the objects come from another UOW, they could "resist" deletion (I wouldn't mind if they did), but when they are attached to UOW - they should be deleted.

Where is the mistake in my analysis?

Calling UnitOfWork.Remove(entity) will attach that entity to the UnitOfWork since you have asked that UnitOfWork to remove it. That said, performing an Attach prior will effectively do the same thing (just in a slightly different ordering) and should not affect any behavior of the removal query.

I have run up your code here using a fairly simple model replicating what you have described above, and things run as expected which is that the entities are being removed regardless of the attach calls.

Are you able to send through a copy of your model and some sample data? If so we can have a bit more of a look into what might be going on here since that doesnt sound right.

Jeremy

I attach my example. It is an attempt to use LightSpeed (we call it a prototype), so please excuse me for all the code commented out.

To see the described behaviour, please:

1. Unzip the code
2. Add Mindscape dlls and SQLite dll to Lib folder
3. Run the solution. It will create the database - using the migrations, I like very much :-)
4. Click the AddStoreysAndApp button, and then "Save changes"
5. Click "ClearStoreys" and then "Refresh" - nothing changes.

The ClearStoreysExecute() in DMPProject.cs is executing the code from my first post. Storey = Item, Appartment = SubItem.

Thanks for the sample, I have looked into this and found the cause of the issue. Basically the items are not being removed because they were not in the identity map for that UnitOfWork, why that is however in this particular case hinges on a bug on providers (e.g. SQLite) where Guid values are stored and returned as strings.

I have added a fix for the issue regarding the Guid/string disparity, however its probably worth elaborating on what the underlying issue is because you may well run into similar issue when dealing with objects from multiple unit's of work being attached back to a new unit of work.

This fix will be available in the next nightly build (20101208) and above.

The reason you were seeing a difference in behavior between having the highlighted code and not is that the collection of Storeys in your Storeys collection and the collection of Storeys collected by association with the objects in the Appartments collection (via the Storey association) are actually 2 different copies of the same object.

When you attach the Appartments collection it walks the tree and attached all loaded associated objects to the same UnitOfWork. You are then deleting the objects in the Storeys collection via UnitOfWork.Remove(entity) calls, while these objects are attached to the UnitOfWork the copy which is held in our IdentityMap (L1 cache) is actually the other copy of the object and this is not marked for deletion.

When you call SaveChanges() it is the IdentityMap which is checked for changes and this has copies which are not marked for deletion hence nothing happens.

The reason this could cause problems for you in the future is that objects loaded within the same UnitOfWork should always return the same copy if it is held in the IdentityMap - due to the previously mentioned bug, this was not happening but it will in future - however if you were to load Storeys in one UnitOfWork and Appartments in another then you would have the same behavior (2 copies of the same entity) and you would see the same problem as is currently demonstrated, so just a heads up that if you are holding global collections of objects are you are which are detached from their UnitOfWork, make sure they are loaded in the same UnitOfWork originally (you are currently doing this, so thats good!).


Jeremy

Thank you very much for your fast reaction. I'll download the nightly build when it's available and check it.

However, I have to take a decision whether to use many short-lived UOWs or one UOW (single per program lifetime). Our database usage is quite specific - we'd like to use LightSpeed as data provider for CAD program. In such program almost all the objects can be accessed at any time, and it is very hard to make i.e. UOW for a single form (as it may be used in a typical DB application).

So the question is: in your opinion - is it better to keep one UOW for program lifetime (considering the possibility of database connection loss - i.e. as described in http://www.mindscape.co.nz/forums/Thread.aspx?PostID=9811) or to juggle with short-lived UOWs and manually maintaining uow.Attach ?

It somewhat depends on the behavior of your application.

If your application can expect to be connected (other than in an exception case) then you should use a globally accesible service for managing your UnitOfWork and it would be sensible to implement a custom connection strategy to handle the cases where the database connection is closed or there is a network error etc.

Attaching the entity and then re-persisting it via SaveChanges() makes sense if your model is more occasionally connected, but as you say you do have to do more juggling and you may run into issues with lazy loading throwing exceptions because it has be disassociated from its original UnitOfWork.

Jeremy

Everything works fine on the nightly build. Thank you. :-)