Sorry I read too fast. Indeed if you are working from the representation in memory and not
considering what happened in the backend, I don’t think it should happen or as you say
something is fishy (like multi-thread abuse).
On 30 Sep 2014, at 09:10, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Thanks for coming back on this :)
2014-09-29 18:16 GMT+02:00 Emmanuel Bernard <emmanuel(a)hibernate.org>:
I think that can happen due to the weak transactional guarantees the
underlying backend provides.
Why do you ask? (that is if you remember as this email is quite old -
nothing like being stuck on a place for 12 hours to catch up ;) ).
I'm not entirely sure anymore why I asked :) Maybe I considered to guard against it
using an assertion.
Does it really depend on the capabilities of the store, though? Between loading an
Association and removing a RowKey from it, all is in our control (and all in one thread).
So if we invoke Association#remove() for a RowKey which isn't present in the loaded
Association object, it still seems fishy to me.
Note that's different from trying to remove an association row in the store actually,
there it may be gone already of course.
On Wed 2014-08-27 22:40, Gunnar Morling wrote:
> Hi Emmanuel,
>
> Is there any legitimate case where Association#remove(RowKey) is invoked
> for a key which is not present in that specific association instance? Or
> would this indicate some programming error?
>
> Thanks,
>
> --Gunnar