Possible bug in UnitOfWork.Remove()?

I am wondering if I have run across a possible bug, or if I am doing something wrong? Here is the guts of our generic depot 'delete' function, which deletes an entity from the database:

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin; mso-bidi-font-family:"Times New Roman"; mso-bidi-theme-font:minor-bidi;}

        public virtual bool Delete(
            object id)
        {
            var uow = UOW.Get;
            TEntity entity = uow.FindById<TEntity>(id);
            if (entity == null) {
                // The entity was not found, so return false
                return false;
            }

            // We found the entity, so remove it
            uow.Remove(entity);
            uow.SaveChanges();
            return true;
        }

The problem is that in my unit tests for the depot, I first create some entities by adding them to the database, then I delete the first and last ones (ID #1 and #250). Then the last thing I do is call the delete function again, to make sure deleting ID #250 again false because the entity is already deleted. However this fails in my unit test.

When I debug the code I can see that on the second call to delete the entity, the FindById() function call returns a valid entity! Even though I already deleted that entity a few lines earlier (so it shoudl be gone from the identity map). I have checked the generated SQL and it is clearly deleting the entity, and when I check the MySQL database after the first delete, the entity is gone. So when the next FindById() is called, it should not be returning anything.

I have verified the problem is the entity is still in the identity map, because if I chagne my code to use SaveChanges(true), which clears the identity map, the problem goes away.

Am I doing something wrong, and I am supposed to always call SaveChanges(true) after deleting an entity, or is this actually a bug?

WTF? I guess I should give up on trying to nicely format the code :)

Any suggestions on this one?

By default (at the moment), entities remain in the identity map after a pending delete is saved, because the SaveChanges operation does not modify the identity map, it just flushes the changes in the identity map to the database.

You can change this behaviour by setting LightSpeedContext.CompatibilityOptions to include ClearDeletedEntitiesOnSave.  This will remove deleted entities from the identity map during SaveChanges.

Unit tests which want to verify what is happening in the database should usually call SaveChanges(true) precisely to avoid getting stale info from the identity map.  Short-running units of work (e.g. Web applications) usually don't need to bother (and don't care about whether deleted entities stick around) because they normally don't re-read the same data after doing a save.  However if you are using a long-running unit of work (e.g. WinForms or WPF application) in your production code and you want your tests to exhibit the same behaviour then of course you do need to call the same overload so that your tests reflect the danger of stale data.

Yes, that makes sense that most short running unit of works (which ours is, even in a unit test as it is tossed at the end of each test). I suppose I can just be explicit about it in the unit tests as you suggested, and do a SaveChanges(true) in the unit test to ensure the identiy map is tossed. That would provide better performance at runtime, and like you say, once code deletes and entity it won't be trying to load it again as it will assume it is gone.

Man, I am not thinking straight today. I meant to say "Yes, that makes sense that most short running unit of works don't care if an entity is not gone from the identity map after delete".

Is Remove supposed to mark entity as removed, or actually remove it from the database?

We're getting a weird Oracle exception about table/view not existing, on the "Remove" call itself (not the subsequent SaveChanges, which never gets executed). Thank you.

It marks the entity as removed. The DELETE is not performed until you do a SaveChanges().

However, the Remove() method does query the database to determine what other entities depend on the one being removed, so that if these entities are in memory it can mark them as deleted too. Your error will be arising during this process of checking for dependent entities.

Yes, turned out another entity was missing a table - thank you.