Hi John, think I brought it up some years ago and we just decided to not support it there (ie it would be another API - which is what does spring actually). In one word: 2nd '-'. In term of impl I think it makes sense since you will just redefine a layer which doesnt make sense between us and the underlying "driver" just for our need and this layer would have specific entries to support all features which would look weird in term of API.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber <http://www.tomitribe.com> 2015-12-07 13:00 GMT+01:00 John D. Ament <[email protected]>: > All, > > I have a question I'd like to raise to the broader group to get opinions. > > Currently, if you compare features, one way that Spring Data beats us is > that their data module can support different types of data stores (Mongo, > Redis, Neo4j etc). Currently we only have a JPA provider. I was wondering > how that might look if we were trying to support other data stores? > > Now I'm not pitching that we'll bring other data stores in. I know that > some others on this list have a very rigid view that we should only support > EE based technologies which is fine. But I was at least thinking that we > could provide hooks for others to build connectors for other stores. > > The couple ways I've though of are: > > - Additional properties on @Repository to control the type [e.g. > @Repository(type="jpa")] > - New partial bean bindings (so instead of @Repository, some other > annotation). > > The goal being that by wiring in a few classes you can get support for your > data store. > > John >
