[hibernate-issues] [Hibernate-JIRA] Commented: (HSEARCH-183) @IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields

@IndexedEmbedded(prefix="") should either be forbidden or fixed with duplicate ID fields ---------------------------------------------------------------------------------------- Key: HSEARCH-183 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-183 Project: Hibernate Search Issue Type: Improvement Components: mapping Affects Versions: 3.0.1.GA Reporter: Stephane Epardaud If all my entities have their ID property named "id" and they use @IndexedEmbedded(prefix="") then there will be several fields named "id" per document. This results in very unfortunate behaviour when indexes are updated because this id is then used by HS to remove Lucene documents, so instead of removing only the one document we are updating, HS removes all documents whose ID have been embedded in the index. We use prefix="" in order to accumulate embedded entities' "text" fields into the root entity so that we can search on any "text" field, embedded or not. This is required because there seems to be no support for a term wildcard such as "*.text:foo" which would search on any term ending by ".text" for the string "foo". Either prefix="" is supported, and this behaviour should be changed, or at the very least trigger a visible warning, or it is not supported and it should be documented and an exception should be thrown. Since it is behaviour I need, I favour supporting it, so I've patched DocumentBuilder to store the ID of the root entity in a special field like _hibernate_class, so that when we update the index only the appropriate entity index document is removed. This works well, but has the side-effect of ignoring the name of the ID as specified in @DocumentId. An alternative would be to still store the root ID is a "special" field, and keep storing the ID under a field name as specified by the user. As long as we only use the "special" ID for index updating all will work well. I can produce both patches and documentation if you agree (and choose).