@ContainedIn does not work on deletes.
Description
Activity
Kyrill Alyoshin October 11, 2010 at 5:39 PM
Yes, I should do that. I may be able to find some time within the next two weeks.
Sanne Grinovero October 10, 2010 at 10:54 PM
Kyrill, I've closed it as it's not a bug, as we agreed it wasn't meant to be used like this. Still I think you've highlighted an interesting concept and I'm wondering if we couldn't improve on this. If you want to create a unit test for this and attach it to a new issue of type "improvement", I'll be happy to think about it, but can't make promises as I'm not sure if it's technically doable, nor how complex it could be.
Kyrill Alyoshin October 8, 2010 at 4:34 PM
Fair enough. You can close the issue.
Sanne Grinovero October 8, 2010 at 4:29 PM
I agree with your point, it's sad that it's needed to change both parts of the Java collection, but really that's a limitation of the way collections are used; Hibernate can't do much about that.
Hibernate will use one or the other collection as "source" to apply modifications; the most simple strategy for user code to make sure that's going to happen is to mandate as best practice to always mandate both sides - this point is strongly stressed at all hibernate courses and books, so your best bet is make sure that all "helpers" in your code update both sides.
Of course, if you have an idea, we'll be glad to hear about it.
Kyrill Alyoshin October 8, 2010 at 4:17 PM
Yes, I think we're talking about the same thing. I realize that whenever a child entity is modified, Hibernate Search will behind the scene fetch its parent to reindex it. I realize it. I just thought that having to manually remove a given child from the collection inside the parent may be too restrictive. I probably should go and submit a patch in the documentation to clearly state that, "if the child is going to be deleted, it must be manually removed from the collection inside the parent for the index to be updated".
This requirement did catch me by surprise, I must say... It is so easy to introduce asymmetry between what's in the DB and what's in the index. Think about it...
So, let's say we have a @Indexed entity Vendor (the parent) that is in a bi-directional @OneToMany relationship with entity Address (the child). Vendor maps the collection of Address'es as @IndexedEmbedded. Address is NOT @Indexed but does map its parent vendor association as @ContainedIn.
Whenever Address entity is retrieved and session.delete'ed, the parent Vendor's index is NOT updated. Everything works fine with update operations.
This obviously happens because the collection of addresses in parent vendor still contains the deleted address. (If the deleted address is manually removed from collection, everything works fine).
Now... I realize that it is not in Hibernate style to automatically severe the association when a child entity is deleted. However, it seems that Hibernate Search should provide such functionality. This does lead to very subtle, hard to diagnose bugs. I assume when Vendor's collection is flushed it is fairly trivial to detect which addresses have been deleted and which not (inside the listener).