[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-472?pag... ] Dobes Vandermeer commented on HSEARCH-472: ------------------------------------------ And you may also see my original forum post https://forum.hibernate.org/viewtopic.php?f=9&t=1003298&p=2427218... -- 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-472?pag... ] Emmanuel Bernard commented on HSEARCH-472: ------------------------------------------ I'm wondering if we could implement that while implementing the ability to add new entities dynamically to the search factory. This is something that would involve emptying the queue of work, closing indexes and reopening them, so it would create some kind of soft downtime. -- 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-472?pag... ] Emmanuel Bernard commented on HSEARCH-472: ------------------------------------------ I've studied the code, we need to: * have a way to declare how many more shards we need * create the additional DirectoryProviders * add the new DPs to DocumentBuilderIndexedEntity (seems to be read only from here) * add the new DPs to the index sharding strategy (probably by adding a new "update" 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-472?pag... ] Emmanuel Bernard commented on HSEARCH-472: ------------------------------------------ Based on what should the strategy start a new shard? That might work let me think about it. -- 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-472?pag... ] Emmanuel Bernard reassigned HSEARCH-472: ---------------------------------------- Assignee: Emmanuel Bernard -- 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-472?pag... ] Sanne Grinovero commented on HSEARCH-472: ----------------------------------------- true, clustering would be problematic - a notification to clients must be send about the full list of available shards; I'd implement it with Infinispan, providing a shared cache containing {shard-business-key, DP configuration} but wouldn't like to introduce Infinispan at this level. The use case would be when sharding by a business key, for example city name for addresses, and a new city name is inserted in the database while previously unknown: a new shard should be started. Sharding by business key is quite cool as it can enable usage of HSEARCH-251 -- 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-472?pag... ] Dobes Vandermeer commented on HSEARCH-472: ------------------------------------------ @Emmanuel, In our case we have a multi-tenant architecture and we want to have separate indexes for each tenant since there is no case where a search would span multiple tenants and memory usage is linearly related to index size. The tenants are provisioned by a user when they sign up a new "business" in our system, which is an entity we create and insert into the database. So, the creation of new shards would happen frequently, but not as frequently as some other operations. It is also fine for us to manually request a new shard creation, as long as the error messages are clear when we have forgotten to do so and insert something with a reference to a non-existant shard. I suppose in an ideal world (for our use case) we'd be able to annotate a collection as full-text searchable and hibernate would automatically create a separate lucene index for each instance of that collection, since clearly searching that collection would not search any other collection at the same time. Then provide an API for doing full-text-search on a persistent (or even not-yet-persistent!) collection. -- 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-472?pag... ] Emmanuel Bernard updated HSEARCH-472: ------------------------------------- Fix Version/s: (was: 3.3.0.Beta3) 3.3.0.CR1 -- 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-472?pag... ] Emmanuel Bernard updated HSEARCH-472: ------------------------------------- Fix Version/s: (was: 3.3.0.CR1) Too much to polish for 3.3 -- 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-472?pag... ] Sanne Grinovero updated HSEARCH-472: ------------------------------------ Fix Version/s: (was: 3.4.0) 3.5 -- 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-472?pag... ] Sanne Grinovero updated HSEARCH-472: ------------------------------------ Fix Version/s: (was: 4.0.0.Alpha1) 4.0.0.Alpha2 -- 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-472?pag... ] Sanne Grinovero commented on HSEARCH-472: ----------------------------------------- http://lists.jboss.org/pipermail/hibernate-dev/2011-August/006894.html -- 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-472?pag... ] Sanne Grinovero updated HSEARCH-472: ------------------------------------ Fix Version/s: (was: 4.0.0.Beta2) 4.0.0.CR1 -- 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-472?pag... ] Sanne Grinovero updated HSEARCH-472: ------------------------------------ Fix Version/s: (was: 4.0.0.Final) 4.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira