Question

I’m using (fluent) nhibernate and I’ve run into a little problem. My data model is to have a user object with a one-to-many link to another object (I’ll call it Obj1).
Obj1 has a primary key that is external to my application. While I could change it to have it’s own primary key and therefore allow duplicates, it would cause more problems later.

The user can add and remove Obj1’s from their profile whenever they like and the data layer is called immediately when each action is performed. The problem is that if a user adds an Obj1, removes it and then adds it again, then nhibernate gives me a NonUniqueObjectException.

This is because the first Obj1 that is added still seems to be hanging around in the nhibernate session. There seem to be several solutions to this:

1. Clear session and reload the user obj when updates occur.
2. From here: nhibernate : a different object with the same identifier value was already associated with the session: 2, of entity: – evict the user object from the session cache after each update.
3. Re-write the screen that allows the user to manage Obj1’s so that it only calls the data layer when leaving the screen.

1 and 2 are easier but both seem a little hack-ish. 3 seems like the ‘proper’ solution but means I may well come up against the same issue in a more difficult to solve area later on.

So the question is, which is best and why? Are any of these solutions really bad for some reason? (For example, trying to micromanage the nhibernate cache just seems like a bad idea to me.)

Note: strangely enough, by writing this I’ve gone from being totally unsure to pretty convinced that 3 is the best way to go. I’d still be interested to hear other points of view though.

Answer 1

I added a unit test on the repository to reproduce this problem and to my surprise, it worked fine.
After a few minutes I found the real problem – I was not persisting the delete of Obj1 to the data layer. Once I did that, everything worked fine.

Oh well, at least it saved me a lot more work.