[hibernate-dev] Shaping the requirements for the new DocumentBuilder to come in Hibernate Search 6
Hi all,
among the various plans for Hibernate Search 6, one of the reasons we
had to do the Elasticsearch integration sooner as experimental was to
get ourselves a clearer picture of what's going to be needed in terms
of internal cleanup.
Our DocumentBuilder is ancient, and several new features have been
added since it was a well designed, simple piece of code..
So, while we have discussed several wishes already, I started now a
document to try get all our thoughts to converge.
For convenience, pasting the current content below.
-
https://docs.google.com/document/d/1JwKanIRHVTw1LvCdLGyY6EKuyvvQn6gvlkmPGqDjFxw/edit?usp=sharing
I'm not giving comment permissions to the world; anyone who's
interested please answer here or drop me a note, happy to give
permissions to comment to well-intentioned people.
N.B. The document will very likely evolve beyond this email; as it is
now it's an initial brain dump. For example, I haven't thought about
the ES capability of nesting structures yet.
Thanks,
Sanne
Pasting from document =
DocumentBuilder and FieldBridge requirements for Hibernate Search 6.0
* Never import Lucene types; ideally make Lucene an dependency of the
Lucene backend only.
* In a modular world, don’t expect end user code to be able to load
Lucene class definitions.
* Efficient lookup “field name” -> field mappings and its indexing
options; not least:
* Cardinality {always one, optional one, one-many, zero-many}
* Needed for validation of queries, e.g. query for null can use
an “exists” query only in some of these cases, vs needing a null
token.
* projectable alone vs part of multiple fields relating to a single
property (allow projection of Two-Way bridges using multiple fields)
* Might need “group name”.”sub field name” for groups and index time joins
* IndexedEmbedded
* “depth” and navigational graph to be pre-computed: tree of valid
fields and options to be known in advance.
* Navigating into a relation must deal with possibly navigating
into subclasses of the relation type:
http://stackoverflow.com/questions/39516355/indexing-a-interface-in-hibernate-search
* Immutable, threadsafe, easy to inspect/walk mapping tree
* Built and validated at boostrap of the IndexManager
* can’t be updated after that
* Field names and custom FieldType not to be allocated at runtime
* Efficient to validate Queries
* Allow efficient production of an Entity instance into:
* Elasticsearch “document”
* Lucene “document”
* An efficient to serialize “document”
* If it gets easy enough, make our own simple serialization?
* Extensible to other backends e.g. Apache Solr in the future (a
Walkable SPI)
* Pretty printed text to dump the “schema” we’re using from a
given domain model
* Validations and comparisons
* Allow to validate compatibility with an Elasticsearch schema
* Allow to validate compatibility with a Lucene schema
* Walking tree to map to ORM loading strategies
* allow to predict which paths we’ll need to initialize
(database load) for efficient batch loading (graph initialization)
* Allow for accurate Dirty-checking to skip indexing operations
* Allow generation of better MassIndexer queries (fetch join
some of the relations?)
* ID handling: specific care
* ad-hoc encoders for ID
* stricter validation (e.g. cardinatlity, DocValues, Two-Way fieldbridges)
* Support multi-term IDs (composite keys, @IdClass)
* Have different “index id strategies” to have them apply different
logic, i.e. “delete by term” and “update by term” only apply on
single-term IDs.
* ID handling strategy might need to take into account if the index
is shared among types.
* Decoupling from Java “Class” as entity-type identifiers
* Sharding:
* Allow reuse of the same schema for indexes using the same
* Allow reuse of some elements for indexes sharing such elements
* Properties / Field relations
* Handle one property -> multiple Fields as a bidirectional relation.
* Disallow one index field being target of different properties
and/or bridges?
* Representation of “Join points” and Groups:
* allow future production of Lucene documents with index-time join
(write in groups)
* allow efficient Query validation for both index-time and
query-time join options
* Composable
* @ClassBridge, @Field annotations to both contribute to field definitions
* a @ClassBridge of an @IndexedEmbedded to both contribute to the
embedded field definitions
* Include type-bound user custom Bridges (see BridgeProvider) in
the compositions
* Both @ClassBridge and custom Bridges need to trigger on
polymorphic relations as well
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Inheritance mapping in Neo4j
Hi, it makes sense but I don't think we can change the mapping now.
Could you do it as a new option? Would you be able to adjust the
queries as needed?
If you can make it a configuration property, default to the old style
mapping, and log a warning of using a deprecated mapping when the old
one is being used. This implies that people not choosing any mapping
style explicitly will see a warning (as the old one would still be the
default).
Thanks,
Sanne
On 16 November 2016 at 12:42, Davide D'Alto wrote:
> A user created the issue https://hibernate.atlassian.net/browse/OGM-1210
>
> The problem is that when we use the SingleTable strategy in Neo4j we
> add a property DTYPE to the node to discriminate the entities instead
> of using labels.
>
> As an example, given an entity Player that extends Person we create:
>
> (n:Person {DTYPE: Player})
>
> instead of having a node with two labels:
>
> (n:Person:Player)
>
> I think the mapping with multiple labels is more natural than the one
> we currently have.
>
> I was wondering if we should fix this for the next release, the
> problem is that I would need additional information in one of our
> .spi.*Context and it will change the mapping.
>
> The next release should be 5.1.Beta2
>
> What do you think?
>
> Thanks,
> Davide
> ___
> 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
Re: [hibernate-dev] [OGM] Inheritance mapping in Neo4j
Hi,
As I understand it, having 2 labels means that you could search either with
n:Person or n:Player?
Thus if we keep the DTYPE: Player in place in addition to both labels, we
won't break anything, will we?
--
Guillaume
On Thu, Nov 17, 2016 at 2:30 PM, Sanne Grinovero
wrote:
> Hi, it makes sense but I don't think we can change the mapping now.
>
> Could you do it as a new option? Would you be able to adjust the
> queries as needed?
>
> If you can make it a configuration property, default to the old style
> mapping, and log a warning of using a deprecated mapping when the old
> one is being used. This implies that people not choosing any mapping
> style explicitly will see a warning (as the old one would still be the
> default).
>
> Thanks,
> Sanne
>
> On 16 November 2016 at 12:42, Davide D'Alto wrote:
> > A user created the issue https://hibernate.atlassian.net/browse/OGM-1210
> >
> > The problem is that when we use the SingleTable strategy in Neo4j we
> > add a property DTYPE to the node to discriminate the entities instead
> > of using labels.
> >
> > As an example, given an entity Player that extends Person we create:
> >
> > (n:Person {DTYPE: Player})
> >
> > instead of having a node with two labels:
> >
> > (n:Person:Player)
> >
> > I think the mapping with multiple labels is more natural than the one
> > we currently have.
> >
> > I was wondering if we should fix this for the next release, the
> > problem is that I would need additional information in one of our
> > .spi.*Context and it will change the mapping.
> >
> > The next release should be 5.1.Beta2
> >
> > What do you think?
> >
> > Thanks,
> > Davide
> > ___
> > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Inheritance mapping in Neo4j
Yes, I think that if we keep the property and only add the label we
won't break anything in the mapping.
On Thu, Nov 17, 2016 at 2:15 PM, Guillaume Smet
wrote:
> Hi,
>
> As I understand it, having 2 labels means that you could search either with
> n:Person or n:Player?
>
> Thus if we keep the DTYPE: Player in place in addition to both labels, we
> won't break anything, will we?
>
> --
> Guillaume
>
> On Thu, Nov 17, 2016 at 2:30 PM, Sanne Grinovero
> wrote:
>>
>> Hi, it makes sense but I don't think we can change the mapping now.
>>
>> Could you do it as a new option? Would you be able to adjust the
>> queries as needed?
>>
>> If you can make it a configuration property, default to the old style
>> mapping, and log a warning of using a deprecated mapping when the old
>> one is being used. This implies that people not choosing any mapping
>> style explicitly will see a warning (as the old one would still be the
>> default).
>>
>> Thanks,
>> Sanne
>>
>> On 16 November 2016 at 12:42, Davide D'Alto wrote:
>> > A user created the issue https://hibernate.atlassian.net/browse/OGM-1210
>> >
>> > The problem is that when we use the SingleTable strategy in Neo4j we
>> > add a property DTYPE to the node to discriminate the entities instead
>> > of using labels.
>> >
>> > As an example, given an entity Player that extends Person we create:
>> >
>> > (n:Person {DTYPE: Player})
>> >
>> > instead of having a node with two labels:
>> >
>> > (n:Person:Player)
>> >
>> > I think the mapping with multiple labels is more natural than the one
>> > we currently have.
>> >
>> > I was wondering if we should fix this for the next release, the
>> > problem is that I would need additional information in one of our
>> > .spi.*Context and it will change the mapping.
>> >
>> > The next release should be 5.1.Beta2
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Davide
>> > ___
>> > 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
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
