What's the identity of Hibernate OGM's "public API" module?
by Sanne Grinovero
I'm reviewing how we expect people to use the Hibernate OGM modules on WildFly.
Scott mentioned that the JPA subsystem of WildFly automatically adds
the "org.hibernate.ogm" module when the
org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
set.
See also :
- https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
OGM's reference documentation recommends to add the modules depending
on which backend is being used, i.e. for CouchDB:
org.hibernate.ogm services, org.hibernate.ogm.couchdb services
See the difference? We expect people to explicitly import he couchdb module too.
We essentially expect people to use a different API - i.e. a different
classpath - depending on the storage.. that's unusual.
The traditional answer is that you should have one API, but our case
is a bit more complex so let's see the options.
I'd like to get rid of the need specify modules. I see several paths,
some less compelling:
A- consider the "couchdb" module a non-essential, power users only
API which you can only unlock by manually configuring modules.
pros: it's done :)
cons: would we agree that OGM is still compelling even without
those "options" for a majority of basic users?
B- have WildFly inject all these modules on the user's classpath
pros: consistency, no magic, everyone gets the same.
cons: Requires updates in WildFly to support new datastores. Larger
classpath? More conflict potentials? More stuff to "support" ?
C/1- have WildFly "guess" the right dependency set by looking at
additional properties.
pros: exposes the minimum but not less
cons: requires such logic to be defined in JipiJapa, needs long
term stability, needs to deal with multiple (different) PU
configurations.
C/2- have WildFly invoke some helper of ours which defines the
modulesets we want
pros: we can control and evolve this as we realise which mistakes
we're making :)
cons: more complex to define this contract?
My vote goes to B, at least for the short term. C/2 is my favourite in
the longer term, or at least a B which allows us to define new
datastores without needing changes in WildFly.
Orthogonal to this, but to keep in mind: WildFly also injects the
"main" slot exclusively. We'll need a way to pick a specific version,
or at least allow overrides like we do with Search.
Thanks,
Sanne
9 years, 12 months
- 4
- 12
[HSEARCH] Feedback on Elasticsearch presentation
by Emmanuel Bernard
Hey all,
I've done a presentation of the new Elasticsearch integration with a
Elasticsearch developer+advocate. Here are some key inputs from the
listener feedback.
The presentation was a Tools in Action (30 mins) where we took a JPA
app, added Elasticsearch for entity indexing manually (describing
issues) and then restart with Hibernate Search.
There was big interest, so a bit less feature release earlier will help
more than "better" later.
One big feedback is that we need to help people on the analyzer
definition in Elasticsearch (from our metadata):
- map existing ES analyzers to ours
- offer way to define an analyzer and have it pushed with the index
definition when we create them
- figure out a way to embed the additional key options like nbr of
shards when we create the index definition
- offer an export function for our index definition so that people can
curl it themselves
The other part was about mapping:
- support for parent child: parent / child is a bit like Infinispan
grouping where the children are colocated in the same node as the
parent. So it's a single node join. David was not necessarily
recommending me to support that from the get go because we already
handle the right denormalization via HSearch.
- support for nested mapping and nested queries. This is also a
relatively expensive prop so not all nested structure should be mapped
as ES nested. Here we probably should offer a specific mapping
annotation or option and write the nested query accordingly
For the mapping part, we probably should write these down in the FAQ as
to why we don't do them right away and the workaround available.
Emmanuel
10 years
- 1
- 0