I think using the "default" convention is fine. We don't *have to* support multi-clustered set-up if we think it's too troublesome.
2016-03-08 13:28 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>: > On 8 March 2016 at 12:04, Gunnar Morling <gun...@hibernate.org> wrote: >> Hi, >> >> Good question, I have been wondering the same. >> >> I think we could even support this 5.6, essentially it's just a matter >> of structuring the properties and how we read them. I basically >> started with a single cluster to get to something working more >> quickly, but it shouldn't take long to change that now. >> >> Only in the docs we need to make clear that index sharing / queries do >> not work across cluster boundaries. >> >> If we don't do it now, at least let's change the prop name into >> "hibernate.search.default.elasticsearch.host" so it's not breaking if >> we add support for index-specific overrides down the road. > > > Yes it sounds like we agree about HSEARCH-2164 being a blocker. > > But will we regret this? what if we later decide that supporting > multiple Elasticsearch clusters is both of low value and too > problematic? > Not sure if we're yet in a position to be aware of all implications; I > guess I shouldn't worry too much as this is still experimental, yet I > think it would be good to go through our list of features via the > reference documentation and try thinking ahead of what problems that > will introduce. > > I didn't find any point which wouldn't be easy to dismiss but a second > pair of brains would be nice on this ;) > > Thanks, > Sanne > > > >> >> >> --Gunnar >> >> 2016-03-08 12:55 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>: >>> Today our experiments are assuming we're connecting to a single >>> Elasticsearch cluster: one hostname to configure, etc.. >>> >>> I think this is an acceptable limitation for version 5.6 (our first >>> stable milestone to support this integration) but I'm wondering if we >>> should document it as a temporary limitation or as an intentional >>> design. >>> >>> I think that eventually we should allow having different entities >>> (indexes) to be stored on different ES clusters; this shouldn't be too >>> hard to manage as the codebase is already structured around this >>> capability of having different types in different "indexes"; so while >>> a single Elasticsearch cluster can manage multiple indexes (that's a >>> bit of a novel concept) I see no reason to not allow different indexes >>> to be mapped on different clusters. >>> >>> = Am I missing some strong reason to not allow this? >>> >>> = While this will (likely) not be supported in 5.6, should the public >>> API and configuration properties allow for this to be configured >>> per-index already? (Changing it later would be a breaking change) >>> >>> See also: >>> - https://hibernate.atlassian.net/browse/HSEARCH-2164 >>> >>> Thanks, >>> Sanne >>> _______________________________________________ >>> 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
