[wildfly-dev] update on WildFly NoSQL prototype integration...

[Scott Marlow]

On 05/12/2016 08:41 AM, Sanne Grinovero wrote:
> On 12 May 2016 at 12:24, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>>
>> On 11 mai 2016, at 16:02, Scott Marlow <smarlow at 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.

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

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