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

[Davide D'Alto]

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

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

+1
This looks like a nice trade-off.
It will allow us to create a POC that can eventually evolve into a separate
project.



On Thu, May 12, 2016 at 1:41 PM, Sanne Grinovero <sanne at hibernate.org>
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.
>
> 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.
>
> Thanks,
> Sanne
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160512/40249dbe/attachment-0001.html