> Interesting, I really need to take a closer look at ES and its APIs. > > How does it react when searching on an un-indexed field? If we can detect > the situation and raise a meaningful exception indicating that an index is > missing so a given query can't be run (could even be done during start-up > for named queries), then I'd say that's good enough, at least for a first > iteration? In particular if we add support for @Index so a user can react. > As said that solution would only be a work-around until we can delegate > that task to HSearch (which then would have the same challenge probably).
Hi all, I think the idea of decoupling HSearch backend from Lucene so that it could be used together with Elasticsearch and Solr is pretty interesting. I've discussed this with Sanne a while go, it's nice to see it is gaining traction :) With relation to Elasticsearch, it will index everything by default. From the input Json document, it will "guess" the type based on the Json type, and apart from that it'll save the whole document in a stored Lucene field called _source (and also in the transaction log, for recovery and replication purposes). It is possible to override the indexing behaviour of course, by providing a custom mapping for the indexed 'type', being a 'type' the equivalent of an 'entity'. Since every single operations can be done via Rest API, it is straightforward to drive configuration form other sources. Gustavo _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
