I chatted about this with Yoann directly; for the sake of others:
true sometimes a ticket is missing when we're discussing milestones
for long-term plans. When we have to break up significant "behind the
scenes" refactorings in smaller steps which can be merged at minimal
risk, which taken as individual tasks don't have much meaning, we
create JIRAs while making progress - as that's when we get a better
idea of what is needed in practice.
In this case it's:
-
https://hibernate.atlassian.net/browse/HSEARCH-1404
It's marked "for version 5.x"; there are many tasks in this cathegory
which are "nice to have" but not blocking any specific release. I just
happen to have been able to finally work on this in the scope of 5.8,
but we'll only merge it if I happen to be able to finish it w/o
changing any public API.
Yoann is right about this needing a separate mechanism to transmit a
schema and configuration to the server: this patch taken individually
doesn't provide much of benefit. It will be useful when combined with
other future tasks, hopefully benefiting from lessons learned while
implementing the Elasticsearch support as it has similar needs.
Thanks,
Sanne
On 11 May 2017 at 09:01, Yoann Rodiere <yoann(a)hibernate.org> wrote:
Hello,
In our roadmap for 5.8, we have this:
Removal of class definitions from master nodes
> The integration of a "master node" needs to be simplified, both in terms
> of user configuration and implementation. We plan to not need user classes
> (entities) on such a node, so that in future it could be a separate
> download which works out of the box with minimal configuration.
I guess what you are doing, Sanne, about replacing Class<?> references with
an internal binding representation, is part of that, but there doesn't seem
to be any trace of those efforts in JIRA.
Is there a ticket about this? I don't think there is one with a 5.8 "Fix
version", but maybe somewhere else... ?
On a side note, there may be hidden complexity in having
mapping-independent master nodes: we can probably use a generic
representation of documents for document additions/updates, but with
Elasticsearch, and probably very soon also with Lucene 7, we need to
initialize indexes with a schema. So at least one node needs both write
access to the indexes *and* knowledge of the mapping... Which
mapping-independent master nodes would prevent.
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev