6:12 p.m.
On 12 May 2016 at 14:50, Scott Marlow <smarlow(a)redhat.com> wrote:
On 05/12/2016 08:41 AM, Sanne Grinovero wrote:
>
> On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>>
>>
>>
>> On 11 mai 2016, at 16:02, Scott Marlow <smarlow(a)redhat.com> wrote:
>>
>>>> Hibernate OGM should still be usable without WF; So maybe there should
>>>> be a separate project/repo which defines an SPI to obtain/manage
>>>> connections and implementations for different NoSQL stores?
>>>
>>>
>>> Excellent suggestion, perhaps the SPI could be under
>>> https://github.com/jboss, which is a common area for sharing. Possible
>>> locations for creating the per NoSQL store implementations could be
>>> https://github.com/jboss or https://github.com/hibernate or
>>> https://github.com/wildfly.
>>
>>
>> I'm starting to think that this might be way overkill. If we are creating
>> a sub project just to share between 20 and 50 lines of code per provider and
>> the overhead code to abstract property configuration to plus OGM and WF
>> ones, we are losing more than gaining.
>>
>> Thoughts ?
>
>
> I agree it's overkill, and have an alternative proposal:
>
> Hibernate OGM should define an interface which is appropriate for its
> own consumption; the Wildfly NoSQL subssystem can have its own
> interface so to not depend on OGM, but they would be somewhat similar
> for each given NoSQL technology we intend to support in this way.
Just to clarify what we were discussing. The idea for sharing connection
setup, would of involved extracting that code from OGM, into a separate jar
that OGM + WildFly NoSQL could depend on.
My impression is that the code to setup these connections trivial, so
there is no much benefit in sharing code.
Hibernate and WildFly generally read configuration setting in
different ways (and conventions) so it might even be preferable to
avoid sharing anything.
I'd aim at injecting the WildFly representation of "NoSQL connection
provider" into Hibernate: in this case all what we need to agree on is
an interface.
Hibernate OGM will also be able to interpret its own configuration
properties as an alternative.
This conceptually maps to the existing case of Hibernate ORM, in which
two different approaches can be used:
- use a Datasource (managed by the app server)
- configure all JDBC settings explicitly, and optionally connection
pooling settings.
In the WildFly case, what OGM needs is for you to inject a "NoSQL datasource".
> Then JipiJapa can inject an adaptor into the OGM boostrap phase,
> delegating from one to the other. So only the OGM specific JipiJapa
> module would need to depend on both interfaces.
> If this dependency is not desirable either, then I think we can live
> with a non-typesafe generic provider of things.
I'm not exactly sure of what you mean here about JipiJapa injecting an
adaptor into the OGM bootstrap phase. Are you talking about how we want to
have a JipiJapa adapter for OGM, that (magically) leaks native NoSQL
dependencies into application deployments, depending on which NoSQL backend
store is targeted? That may be different than what we are talking about
here but that also needs a SPI, so the JipiJapa adapter can ask the JPA
PersistenceProvider what the backend store is (or something like that).
Ideally JipiJapa should work similarly to how it does with a JTA
DataSource: some identification string, like an URL or a JNDI name,
will be listed in the persistence.xml and this needs to match the
configuration of some NoSQL datasource.
By "adaptor" I was merely referring to the fact that whatever JipiJapa
will give to Hibernate OGM, this should implement an interface from
OGM so that this can be consumed.
[1] talks about some of the (OGM/ORM related) dependency issues that are
also important to solve. I'm not really sure of the best way to address the
[1] dependency issues that involve WildFly Clustering, WildFly JPA
container, WildFly JipiJapa adapters for Hibernate ORM,
Hibernate-Infinispan, Infinispan.
I agree with Gunnar, that we should continue with POC coding but also really
love the feedback/discussion going on here. I'd like to ping some
additional teams as well soon (Infinispan dev, native NoSQL store teams,
others that may need to extend the WildFly NoSQL infrastructure).
Scott
[1] https://github.com/jboss/jboss-nosql/issues/3
>
>
> Thanks,
> Sanne
>