[hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

[Gunnar Morling]

2016-03-30 18:15 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> 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#JPAReferenceGuide-Determinethepersistenceprovidermodule
>
> 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.
>

That has been an explicit choice; Different stores e.g. expose different
mapping strategies and configuration options. There are annotations and a
fluent API which live in the respective modules, allowing the user to
configure these specifics in a safe way. Instead of exposing the super set
of all these specifics from all stores in one common API, we pushed these
specifics to the backend modules (with some re-use within a type of store,
say document stores, where it made sense).


> 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?
>

No, that's not really feasible. Users need to be able to access these store
specifics.

 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.
>

Yes, C/2 would be nice to have.

Although I don't see a big issue in demanding to add a specific module
dependency. It's documented and I don't think I remember any user report
complaining about it. People also add dependencies to their Maven POM :)

Another question is how to deal with backends not part of the "official"
OGM package. Would users have to fall back to the explicit dependency for
those?

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.
>

That's the beauty of manual configuration: People can select the slot they
want :) Right now I don't see a huge benefit in replacing one property in
the manifest with another property in persistence.xml.

All in all I feel it might be a nice improvement, but I don't think its
impact is huge.

Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>