[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-471?pag... ] Emmanuel Bernard commented on HSEARCH-471: ------------------------------------------ Hi, I don't quite understand the use case, can you give some concrete examples? -- 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-471?pag... ] Emmanuel Bernard updated HSEARCH-471: ------------------------------------- Summary: Ability to selectively index an entity based on its state (was: Ability to "filter" entities from the search indexes) Ah ok. Ability to "ignore" an entity for indexing / reindexing based on its state. That might be interesting. It's not 100% trivial however: - ignore means triggering an index delete for update and delete - what about @IndexedEmbedded of this entity; probably safely ignore them - what about @ContainedIn: should probably make the ignore flag be ignored :) - wonder how well that would play with the collection change navigation Do you think the full-text search perf gain will be significant? -- 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-471?pag... ] Sanne Grinovero commented on HSEARCH-471: ----------------------------------------- +1 on this, it's not an unusual question on forums either. the searches won't be speeded up much, but surely some memory is spared and some index changes too (avoid the insert/update work), which in turn makes cached filters possibly live longer, etc.. what about something similar to @DynamicBoost ? how will we detect if an entity changed from "indexed" to "nonindexed"? it should be deleted from index in that case. -- 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-471?pag... ] Emmanuel Bernard commented on HSEARCH-471: ------------------------------------------ About the sharding per fk. I think you can by passing the fk in the Lucene Document and using it in IndexShardingStrategy#getDirectoryProviderForAddition -- 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-471?pag... ] Emmanuel Bernard updated HSEARCH-471: ------------------------------------- Fix Version/s: (was: 3.3.0.CR2) 3.4.0 -- 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-471?pag... ] Sanne Grinovero commented on HSEARCH-471: ----------------------------------------- we started a discussion on this topic on the mailing list: http://lists.jboss.org/pipermail/hibernate-dev/2011-January/005910.html Please join there and comment to shape the best API -- 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-471?pag... ] Sanne Grinovero commented on HSEARCH-471: ----------------------------------------- It seems people have been doing this by extending the FullTextIndexEventListener, but since moving to Hibernate Core 3.6.x that's not an option anymore, and we want to make that class final anyway. I'm going to push up the priority on this: https://forum.hibernate.org/viewtopic.php?f=9&t=1010513 -- 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-471?pag... ] Sanne Grinovero updated HSEARCH-471: ------------------------------------ Fix Version/s: (was: 4.0) 4.0.0.Alpha1 -- 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-471?pag... ] Hardy Ferentschik edited comment on HSEARCH-471 at 9/9/11 3:57 AM: ------------------------------------------------------------------- up until some recent restructuring of FullTextIndexEventListener and EventSourceTransactionContext i was able to implement something like this very easily. first, my use case: we have a few objects that are expensive to index but are modified "a lot". we only want them indexed at a few well defined transitions: initial creation and when certain members are modified. otherwise, we don't need them to be reindexed. to solve this issue with earlier versions of hib-search, we extended FullTextIndexEventListener and overrode processWork. we map classes to MVEL expressions and use the MVEL expressions to evaluate whether or not to index the entity. we define the FullTextIndexEventListener in spring and configure it like: {code} <bean id="fullTextIndexer" class="com.example.dao.hibernate.FullTextIndexEventListener"> <property name="entityChecks"> <map> <entry key="com.example.model.RetailTransaction"> <value> if (event is org.hibernate.event.PostUpdateEvent) { return (oldState.suspended != newState.suspended || entity.getTransactionState().name() != "PENDING") } return true; </value> </entry> </map> </property> </bean> {code} then instead of autoregistering the default listeners, we register this new listener with the appropriate events. for our particular use case this helped us out quite a bit. however, it looks as though we aren't going to be able to do this in the near future because of the redesign of EventSourceTransactionContext and FullTextIndexEventListener. EventSourceTransactionContext.getIndexWorkFlushEventListener looks thru the listeners for the FullTextIndexEventListener like so: {code} for (FlushEventListener listener : flushEventListeners) { if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { return (FullTextIndexEventListener) listener; } } {code} which means our subclass of FTIEL isn't be found. plus, it looks as though FTIEL will soon be final. so, i don't know if we've been "abusing" the system here, or what, but this seemed like a fairly straight forward way of implementing conditional indexing and has worked really well for us for quite some time. i'm not suggesting that hib-search make a dependency on MVEL, etc; however, it would be nice if we were able to continue to subclass FullTextIndexEventListener in the way that we have been. was (Author: visionlink): up until some recent restructuring of FullTextIndexEventListener and EventSourceTransactionContext i was able to implement something like this very easily. first, my use case: we have a few objects that are expensive to index but are modified "a lot". we only want them indexed at a few well defined transitions: initial creation and when certain members are modified. otherwise, we don't need them to be reindexed. to solve this issue with earlier versions of hib-search, we extended FullTextIndexEventListener and overrode processWork. we map classes to MVEL expressions and use the MVEL expressions to evaluate whether or not to index the entity. we define the FullTextIndexEventListener in spring and configure it like: <bean id="fullTextIndexer" class="com.example.dao.hibernate.FullTextIndexEventListener"> <property name="entityChecks"> <map> <entry key="com.example.model.RetailTransaction"> <value> if (event is org.hibernate.event.PostUpdateEvent) { return (oldState.suspended != newState.suspended || entity.getTransactionState().name() != "PENDING") } return true; </value> </entry> </map> </property> </bean> then instead of autoregistering the default listeners, we register this new listener with the appropriate events. for our particular use case this helped us out quite a bit. however, it looks as though we aren't going to be able to do this in the near future because of the redesign of EventSourceTransactionContext and FullTextIndexEventListener. EventSourceTransactionContext.getIndexWorkFlushEventListener looks thru the listeners for the FullTextIndexEventListener like so: for (FlushEventListener listener : flushEventListeners) { if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { return (FullTextIndexEventListener) listener; } } which means our subclass of FTIEL isn't be found. plus, it looks as though FTIEL will soon be final. so, i don't know if we've been "abusing" the system here, or what, but this seemed like a fairly straight forward way of implementing conditional indexing and has worked really well for us for quite some time. i'm not suggesting that hib-search make a dependency on MVEL, etc; however, it would be nice if we were able to continue to subclass FullTextIndexEventListener in the way that we have been. -- 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-471?pag... ] Emmanuel Bernard updated HSEARCH-471: ------------------------------------- Fix Version/s: (was: 4.1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-471?page=com.atlassian.jira.p... ] Sanne Grinovero commented on HSEARCH-471: ----------------------------------------- I would expect the actionInterceptor to be applied on subtypes, but am having no clean idea on how to avoid demanding this repetition, unless we make the option mandatory or split it to a different annotation. I still remember that I was initially surprised that @Indexed was not inherited. Could we add an option to have the "indexing feature" inherited, with the same options? Then you could have {code} @Indexed(inherited=true, actionInterceptor=NotIndexAction.class) //default to NOT index, neither this type nor subtypes @Indexed(inherited=false, actionInterceptor=DefaultIndexedAction.class) //current behaviour, with both options at it's default{code} What I don't like is that if I extend a type annotated with Indexed and change for example the index name only, it would be confusing to guess which action is expected: the inherited one or the one defined here? of course the default one, as annotations won't allow us to understand if a value was defined explicitly or not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-471?page=com.atlassian.jira.p... ] Emmanuel Bernard commented on HSEARCH-471: ------------------------------------------ Is there a use case for {code} IndexingActionTypeonDelete(T entity) { return //something other than IndexingActionType.UNCHANGED; } {code} If there is none, we should simply remove this method. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-471?page=com.atlassian.jira.p... ] Emmanuel Bernard commented on HSEARCH-471: ------------------------------------------ Dirtyness happens before in the FullTextIndexEventListener which means that would not be a "portable" solution for non hibernate. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-471?page=com.atlassian.jira.p... ] Emmanuel Bernard commented on HSEARCH-471: ------------------------------------------ We will with server side indexing. Anyways, one safe option is to disable dirty checking (stateInspectionOptimizationsEnabled really) when an interceptor is enabled. I think that's the safe option but it goes slightly against the goal of the performance hunters that would use interceptors to gain a few extra time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-471?page=com.atlassian.jira.p... ] Emmanuel Bernard commented on HSEARCH-471: ------------------------------------------ After discussions with Sanne, we have decided to keep the dirty checking optimization disabled when interceptors are used on a given class. We have several options to enable it down the road. All based on the interceptor implementor giving us more information on what state it uses: - put on the interceptor implementation a @UsesProperties("status") This will be added to the list of properties to consider inside DocumentBuilder.isDirty("") - use a new PropertyUsage interface returning the list of used properties. This interface could be used for class bridges as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/HSEARCH-471?page=com.atlassian.jira.p... ] Sanne Grinovero resolved HSEARCH-471. ------------------------------------- Resolution: Fixed -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira