Hi,
Did the same this week-end, and adapted your work to match the bigger
picture of what we discussed on Friday.
Basically the "StructureTraverser" is now called "ValueProcessor",
because
it's not responsible for exposing the internals of a structure anymore, but
only to process a structure according to previously defined metadata,
passing the output to the "DocumentContext". I think it's the second option
you suggested. It makes sense in my opinion, since metadata will be defined
differently for different source types (POJO, JSON, ...).
This design allows in particular what Sanne suggested: when
bootstrapping, we can build some kind of "walker" (a composition of
"ValueProcessors") from the metadata, and avoid metadata lookup at runtime.
The snippet is there:
https://gist.github.com/yrodiere/
9ff8fe8a8c7f59c1a051b36db20fbd4d
I'm sure it'll have to be refined to address additional constraints, but in
its current state it seems to address all of our requirements.
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
On 27 January 2017 at 18:23, Emmanuel Bernard <emmanuel(a)hibernate.org>
wrote:
I took the flight home to play with free form and specifically how
we
would retrieve data from the free form structure.
By free-form I mean non POJO but they will have schema (not expressed
here).
https://github.com/emmanuelbernard/hibernate-search/commit/
0bd3fbab137bdad81bfa5b9934063792a050f537
And in particular
https://github.com/emmanuelbernard/hibernate-
search/blob/freeform/freeform/src/main/java/org/hibernate/
freeform/StructureTraverser.java
https://github.com/emmanuelbernard/hibernate-
search/blob/freeform/freeform/src/main/java/org/hibernate/
freeform/pojo/impl/PojoStructureTraverser.java
It probably does not compile, I could not make the build work.
I figured it was important to dump this raw thinking because it will
influence and will be influenced by the redesign of the DocumentBuilder of
Hibernate Search.
There are several options for traversing a free form structure
- expose the traversing API as a holder to navigate all properties per
structure and sub structure. This is what the prototype shows. Caching
needs to be accessed via a hashmap get or other lookup. Metadata and the
traversing structure will be navigated in parallel
- expose a structure that is specialized to a single property or container
unwrapping aspect. The structures will be spread across and embedded in the
Metadata
Another angle:
- create a traversable object per payload to carry it (sharing metadata
info per type)
- have a stateless traversable object that is provided the payload for
each access
The former seems better as it does not create a traversable object per
object navigated.
The latter is better for payloads that need parsing or are better at
sequential access since state could be cached.
We need to discuss that and know where DocumentBuilder is going to
properly design this API.
Emmanuel
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev