IMHO passing the shard identifier in the Properties entries is a weak solution in long term.
I shall prefer breaking SPI but no rational thoughts to back my out of the box opinion. Niko 2013/4/11 Emmanuel Bernard <emman...@hibernate.org>: > I am currently working on a solution for dynamically adding new shards > to Hibernate Search (for example one per tenant with a list growing). > > https://hibernate.atlassian.net/browse/HSEARCH-472 > > Things are going well but there is an interesting problem related to a > subsequent feature > > https://hibernate.atlassian.net/browse/HSEARCH-1295 > > In short, EntityIndexBinders create additional IndexManagers when a not > yet created shard id requested. The IndexManager is uniquely identified > by its indexName. > > In the old sharding approach, the index name was turned into indexName.n > (n being the shard number) and this new indexName.n is passed along to > DirectoryProviders etc > > To implement HSEARCH-1295 properly, you need the DirectoryProvider to > have access to the original index name and the shard identifier as > independent dataset. > > We can hack around the model and pass the original indexName and shard > identifier in specific Properties entries. That's backward compatible. > > An alternative is to replace String indexName in all thee contracts with > a proper IndexName object pointing to the original indexName and to the > shard idenfitier. That one breaks a bunch of SPI and in particular > DirectoryProvider. > > Thoughts? > > Emmanuel > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
