[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372?pag... ] Sanne Grinovero updated HSEARCH-372: ------------------------------------ Fix Version/s: 3.1.1 I'm not sure if it's doable for 3.1.1 but at least it gets some consideration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372?pag... ] Emmanuel Bernard commented on HSEARCH-372: ------------------------------------------ Thomas, can you share your bridge implementation. manybe it's not TwoWay. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372?pag... ] Emmanuel Bernard updated HSEARCH-372: ------------------------------------- Fix Version/s: (was: 3.1.1) 3.2.0 Issue Type: New Feature (was: Bug) I've analyzed the code a bit. I think I did not activate this feature because in most ClassBridge, we don't know which field name is used. This could work however: - if the user explicitly adds a name() to the @ClassBridge - and the bridge impl does not mess around and use the field name straight I am contemplating the idea of adding an interface implemented by bridges and declaring which field is used (I dont' think I like the idea very much though as field names could be dynamic), or simply a flag declaring the bridge as a good citizen to increase error discovery. I am not willing to rush an impl of this new feature (with or wo interface) in a micro release but we can help you implement it (see below the key parts that needs enhancement to make it work). Implementation: - DocumentBuilderIndexedEntity.checkAllowFieldSelection does nto take classBridge into account - DocumentBuilderIndexedEntity.processFieldsForProjection does nto take class bridges into account Side note: - DocumentBuilderIndexedEntity.checkAllowFieldSelection does not take embeddedBridges into account, it probably should but we could have some circularity issue? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372?pag... ] Thomas Goetz commented on HSEARCH-372: -------------------------------------- I'm not sure about what exactly you mean by "the bridge impl does not mess around and use the field name straight ". Could you maybe give an example? Or look at my example and tell me if I did anything completely wrong? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372?pag... ] Thomas Goetz commented on HSEARCH-372: -------------------------------------- Ok, in my case it works if I extend DocumentBuilderIndexedEntity.processFieldsForProjection like that: --- snip --- private static void processFieldsForProjection(PropertiesMetadata metadata, String[] fields, Object[] result, Document document) { final int nbrFoEntityFields = metadata.fieldNames.size(); for ( int index = 0; index < nbrFoEntityFields; index++ ) { populateResult( metadata.fieldNames.get( index ), metadata.fieldBridges.get( index ), metadata.fieldStore.get( index ), fields, result, document ); } // handle ClassBridge final int nbrOfClassFields = metadata.classNames.size(); for (int index = 0; index < nbrOfClassFields; index++) { populateResult( metadata.classNames.get(index), metadata.classBridges.get(index), metadata.classStores.get(index), fields, result, document ); } final int nbrOfEmbeddedObjects = metadata.embeddedPropertiesMetadata.size(); for ( int index = 0; index < nbrOfEmbeddedObjects; index++ ) { //there is nothing we can do for collections if ( metadata.embeddedContainers.get( index ) == PropertiesMetadata.Container.OBJECT ) { processFieldsForProjection( metadata.embeddedPropertiesMetadata.get( index ), fields, result, document ); } } } --- snip --- This may not be the desired solution, but as I only use ClassBridge with name() and don't do anything unusual inside the ClassBridge implementations, I can live with that hack for now. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372?pag... ] Emmanuel Bernard updated HSEARCH-372: ------------------------------------- Fix Version/s: (was: 3.2.0.Beta1) 3.2.0.Beta2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-372?pag... ] Emmanuel Bernard resolved HSEARCH-372. -------------------------------------- Resolution: Fixed -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira