[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-662?pag... ] Guillaume Smet commented on HSEARCH-662: ---------------------------------------- Hello, I confirm that this is a real bug and here is an explanation and a proposal on how to fix it. The problem is that in the WorkPlan, works are stored by id in the map: {code} private final HashMap<Serializable, PerEntityWork<T>> entityById = new HashMap<Serializable, PerEntityWork<T>>(). {code} This id is extracted using the extractProperId() method which is: {code} private Serializable extractProperId(Work<T> work) { T entity = work.getEntity(); // 1) entity is null for purge operation, which requires to trust the work id // 2) types mapped as provided id require to use the work id // 3) when Hibernate identifier rollback is used && this identifier is our same id source, we need to get the value from work id if ( entity == null || documentBuilder.requiresProvidedId() || ( work.isIdentifierWasRolledBack() && documentBuilder.isIdMatchingJpaId() ) ) { return work.getId(); } else { return documentBuilder.getId( entity ); } } {code} In the case explained above, we are in the "return documentBuilder.getId( entity );" case and the documentBuilder is a DocumentBuilderContainedEntity which returns null as the id: {code} @Override public Serializable getId(Object entity) { //this is not an indexed entity return null; } {code} So for all the @ContainedIn entities, the id is null and when you add a new one in the queue, it overwrites the previous one and thus you have only one entity reindexed. I think the easiest way to fix the problem is to also return work.getId() in the case of @ContainedIn entities. IMHO, I would test if documentBuilder.getId( entity ) returns null and, if so, I would return the work.getId(). It's the most solid solution on the long term, rather than special casing the @ContainedIn case. Something along these lines should fix it: {code} private Serializable extractProperId(Work<T> work) { T entity = work.getEntity(); // 1) entity is null for purge operation, which requires to trust the work id // 2) types mapped as provided id require to use the work id // 3) when Hibernate identifier rollback is used && this identifier is our same id source, we need to get the value from work id if ( entity == null || documentBuilder.requiresProvidedId() || ( work.isIdentifierWasRolledBack() && documentBuilder.isIdMatchingJpaId() ) ) { return work.getId(); } else { Serializable id = documentBuilder.getId( entity ); if ( id != null ) { return id; } else { return work.getId(); } } } {code} Feel free to ask any further question if my explanation isn't clear. It would be nice to have it fixed in the next version of Hibernate Search. -- Guillaume -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-662?pag... ] Guillaume Smet commented on HSEARCH-662: ---------------------------------------- By the way, I forgot to mention it but the code I quote is from Hibernate Search 3.4.0.Final as we have the problem with this version. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-662?pag... ] Sanne Grinovero updated HSEARCH-662: ------------------------------------ Suitable for new contributors: [Yes, likely] Priority: Critical (was: Blocker) Fix Version/s: 4.0.0.Alpha1 3.4.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-662?pag... ] Guillaume Smet commented on HSEARCH-662: ---------------------------------------- Hi Sanne, I don't think I'll be able to dedicate time to work on it as I don't have a development environment set up for Hibernate Search and I tried to set up one quickly and it's a bit cumbersome. I think I detailed the problem quite well so you should be able to fix the problem very quickly. If you have any question about the problem or if you want me to detail anything, feel free to ping me. Have a nice day. -- Guillaume -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-662?pag... ] Sanne Grinovero resolved HSEARCH-662. ------------------------------------- Resolution: Fixed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-662?pag... ] Guillaume Smet commented on HSEARCH-662: ---------------------------------------- Hi Sanne, Thanks to both of your for fixing it and for publishing a snapshot. Any plan to release a 3.4.1 version anytime soon? We have to release a project soon and we'd prefer to release it with a released version rather than a snapshot. And this is definitely a pretty nasty bug which is quite hard to work around when you have encountered it. Thanks for your feedback. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-662?pag... ] Guillaume Smet commented on HSEARCH-662: ---------------------------------------- Great! Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira