[hibernate-dev] What's the identity of Hibernate OGM's "public API" module?
Sanne Grinovero
sanne at hibernate.org
Wed Mar 30 13:50:17 EDT 2016
On 30 March 2016 at 18:35, Davide D'Alto <davide at hibernate.org> wrote:
> I don't think I like the idea of adding unnecessary dependencies on the user
> classpath.
I don't like it either, but specifically why not?
It would be less "magic" which is usually a good thing in these complex systems.
> If I understand correctly, you would add a lot of dependencies to avoid
> adding:
>
> org.hibernate.ogm.couchdb service
>
> I think this is something that a "Basic user" can handle.
> I don't think it's worth to work for another solution that we don't plan to
> use in the long term.
I'm not sure how to interpret you: are you voting against option B, or
voting against doing any change?
It's not about having the user to have to type just "org.hibernate.ogm
services", rather than "org.hibernate.ogm services,
org.hibernate.ogm.couchdb services" :
it's about the user not needing to add any Manifest, any XML nor
having to read 5 pages of reference documentation about details of
modules configuration in WildFly.
So my proposals are about how to close the final step, so we can remove it all.
>
> My preference goes to C, the user already has to set
> hibernate.ogm.datastore.provider, I think it would be nice to use the same
> property to
> know which module we need.
>
> To clarify to others, for using CouchDB, the user already has to set the
> property:
>
> hibernate.ogm.datastore.provider = couchdb_experimental
>
> There are constants for each available datastore:
>
> ehcache, infinispan, mongodb, ...
Sure, some logic could read out properties, that's C1. The problem for
me is that if this logic is hardcoded in WildFly we're stuck with the
modules it supports and we can't add new dialects in new releases of
OGM.
To implement C/2 I suspect we'll need to expose some contract which
allows us to select it, and JipiJapa/OGM will have to invoke that.. so
at least the contract API needs to be stable in the long term.
Thanks,
Sanne
More information about the hibernate-dev
mailing list