Hi all,

I have a very unpleasant problem.

I have an entity named FinalIn which contains a BAG of child objects named PhysicalStock.

- FinalIn

- PhysicalStock 1
- PhysicalStock 2
- PhysicalStock 3

etc...
So I describe this with a one-to-many relationship in HBM mapping.

<class name="LogSys.LGS.BusinessObjects.Stock.FinalIn, LogSys.LGS.BusinessObjects"
<bag name="Physicals" table="NS_STOCK" cascade="all-delete-orphan"
access="nosetter.camelcase"
lazy="true"
inverse="true">
<key column="FINAL_IN_ID" />
<one-to-many class="LogSys.LGS.BusinessObjects.Stock.PhysicalStock, LogSys.LGS.BusinessObjects" />
</bag>
</class>

So everything is classical. (I just post a snippet of the HBM mapping in order to be more clear)

We have a PARENT class FinalIn that has a CHILD collection of PhysicalStock entities.

We have opened an NHibenate Session (ASP.NET).
During it we create a new PhysicalStock entity and add it to the PhysicalStocks collection of the FinalIn object:
C# code:

/// Adds a Physical Stock to the Physicals collection
/// and sets the parent of the Physical Stock.
/// </summary>
/// <param name="physicalStock">PhysicalStock object.</param>
public virtual void AddPhysical(PhysicalStock physicalStock)
{
physicalStock.FinalIn = this;
Physicals.Add(physicalStock);
}

PhysicalStock newStock = new PhysicalStock();
newStock.Id = 0; // 0 is unsaved-value
...
// fill-in data for newStock
...
finalIn.AddPhysicalStock(newStock);

So the stock is added to the collection (which is of type IList<PhysicalStock>)

After the adding, nhibernate's session is acknowledged that an INSERT statement must be issued against the database for the new PhysicalStock record.

So if we COMMIT the session transaction, a NEW PhysicalStock will be saved in the database, because the PhysicalStocks collection is persistent.

My problem is that if before I commit the transaction, my business rules state that the PhysicalStock is not needed (does not have to be saved).

So I create the PhysicalStock (add it to the collection of the FinalIn), but after a while my business rules state that I should remove it (in a certain situation).

So what I do is:
finalIn.RemovePhysical(newStock);
/// <summary>
/// Removes a Physical Stock from the Physicals collection.
/// </summary>
/// <param name="physicalStock">PhysicalStock object.</param>
public virtual void RemovePhysical(PhysicalStock physicalStock)
{
physicalStock.FinalIn = null;
Physicals.Remove(physicalStock);
}

Session automatically COMMITS transaction on EndRequest.

Problem is that in case I add a PhysicalStock to the FinalIn and then Remove it from the collection, the session give me the following exception:

Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect) for LogSys.LGS.BusinessObjects.Stock.PhysicalStock instance with identifier: 0

Q: Do you have a solution of that when a NEW entity is added to a PERSISTENT collection and then REMOVED from this collection, before the end of the transaction, we don't get the error above?
A:

Thanks in advance,
Pavel Tsekov,
9000 Bulgaria, Varna,
LogSys BG

I suppose you have to evict the newly created object manually from the session: session.Evict(obj). You may think about deferring the add operation until you are really sure that the object should be saved.

Hi Wolfgang,

thanks for you reply, and I seems quite logical, but I still have a pure domain model, and I cannot afford to cal SESSION.EVICT() from inside my objects.

You can imagine. Inside my business objects, I add an entity to a collection. Then I deal with it.

After a while by business logics, decides that this entity is not to by saved.

I don't have a REFERENCE to SESSION because I work with pure business objects.

So I cannot afford EVICT.


Q: Isn't it normal that when an entity is added to a persistent collection and then removed on the next line => this entity is not SAVED?

Agreed ... this behavior is caused by the cascade on the parent. This tells hibernate to add the object to the session. But there is no implicit removal from the session if you remove the object from the session. I furthermore assume, that the association between the parent and the object is not saved just the object itself (meaning the foreign key is null).

If you really want to know what's going on behind the scenes, you have to step through the source code.