Hi John-

Yeah, I was thinking that a JCR store was not my ultimate data storage - it
may be *one* of them, but not the only one.

Basically, we will have data in an RDBMS, in a NoSQL store (like HBase),
one or more data grids (like Tibco, GridGain, Terracotta), file systems and
document storage systems (like Alfresco), Lucene/Solr, and potentially
others.

We are already working on a generic canonical query language which can
represent lookups and queries across multiple stores and types of stores
like this.  We can implement bindings/parsings from that representation to
the specifics of the store to perform queries and return data.  We already
have a canonical data model, and will be generating language bindings and
transport representations of the data.  This is all stuff we are designing
building.  What I'm looking at here is the programming model for developers
to use to access the data - without knowing where or how it is stored and
retrieved.

Therefore, I basically want to express the "query" in our own DSL (or maybe
use JPA-like builders? not sure yet), which we will parse into the generic
query representation... and then pass on to the appropriate data store.

I'm still in the infancy of working out this model.  CDI is fantastic
because it provides the exact framework that I had envisioned (and started
building on my own - but now don't have to).

Your note leads me to another question - basically I have to figure out how
I'm going to put together the partial bean handlers and annotations to
create this programming model.  Without a lot of documentation, I guess I'm
not sure yet the exact relationship between the annotated interfaces and
the invocation handlers.  Is it strictly one-to-one?  Or can it be
many-to-one?  Many-to-many?  How is it managed?

Thanks,
-David-



On Mon, Oct 7, 2013 at 8:05 PM, John D. Ament <[email protected]>wrote:

> Having worked with JCR in the past, I'm not sure how well I would
> recommend using JCR over multiple data stores, ModeShape has a couple
> of connectors, JackRabbit has its internal stores.  Neither are really
> defined for extracting objects from a datastore though, other than JCR
> specific node types.
>
> I'm curious, what other types of datastores are you integrating?  It
> shouldn't be too difficult to create additional partialbean handlers
> that leverage other stores.
>
> On Mon, Oct 7, 2013 at 6:33 PM, Jason Porter <[email protected]>
> wrote:
> > The data module relies on JPA. You may be able to abstract things out
> into
> > your own EntityManager, but I'm think that will cause it's own problems
> and
> > some things may not work for you, though if they do, great!
> >
> > Have you taken a look at JCR (JSR-170 / JSR-283)? That may provide a
> better
> > abstraction for you. If you do decide to go down that route, a JCR
> > integration similar to what we have in the data module could also be very
> > interesting.
> >
> >
> > On Mon, Oct 7, 2013 at 3:23 PM, David Hooker <[email protected]> wrote:
> >
> >> Thanks, Jason.
> >>
> >> I read through that README quickly - does the data module require a JPA
> >> EntityManager?  The reason I'm doing this is to provide data from a
> number
> >> of sources of different types, and don't want to be bound to JPA
> >> underneath.  Is there an extensible way for me to extend the mechanism
> to
> >> be able to plug in different kinds of data providers?  Or should I
> instead
> >> wrap my providers in an EntityManager interface which itself would
> abstract
> >> the various data sources?  (Note, these could include NoSQL, file
> systems,
> >> unstructured data, etc.)
> >>
> >>
> >>
> >> On Mon, Oct 7, 2013 at 4:10 PM, Jason Porter <[email protected]
> >> >wrote:
> >>
> >> > This may not answer all of your questions, but I hope it's a start.
> >> >
> >> > I know the documentation for DeltaSpike isn't the greatest,
> unfortunately
> >> > most (all?) of the developers are currently being pulled away due to
> the
> >> > demands of our day jobs. Any help you're able to give in documentation
> >> > would be a tremendous help.
> >> >
> >> > With regards to the documentation about the data module, have you seen
> >> the
> >> > readme at
> >> >
> >> >
> >>
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/README.adoc
> >> > (or
> >> > the other git address)? If I remember correctly, it makes use of the
> >> > partial bean support and works similar to what is listed in the quick
> >> start
> >> > you mentioned. It also goes beyond that and provides as simpler
> >> abstraction
> >> > to the JPA criteria query, audit logging, it's own extension
> mechanism,
> >> > pagination, etc.
> >> >
> >> > The second question you had about an InvocationHandler and multiple
> >> > interfaces: you should be able to that, though it may be a little
> tricky
> >> > especially if the params differ in types
> >> >
> >> >
> >> > On Mon, Oct 7, 2013 at 2:33 PM, David Hooker <[email protected]>
> wrote:
> >> >
> >> > > Hi list-
> >> > >
> >> > > I'm using Weld as part of building a custom platform in Java SE.
>  I've
> >> > been
> >> > > pointed to deltaspike for some of the things I want to incorporate.
> >> > >
> >> > > First, one of the things I'm looking for is declarative data
> queries,
> >> > > pretty much exactly as seen here:
> >> > >
> >> > >
> >> >
> >>
> https://github.com/jboss-developer/jboss-wfk-quickstarts/blob/master/deltaspike-partialbean-advanced/src/main/java/org/jboss/as/quickstart/deltaspike/partialbeanadvanced/queryservice/PersonQueryService.java
> >> > >
> >> > > This is based on the partial bean stuff, which I'm trying to
> decipher
> >> > from
> >> > > the examples since I can't find any docs or blogs anywhere.
> >> > >
> >> > > So first, can someone tell me the difference between the approach
> here
> >> > and
> >> > > the data module (which I can find even less on)?
> >> > >
> >> > > Secondly, on the partial bean stuff:  it seems that what it does is
> >> allow
> >> > > me to annotate an interface and provide an InvocationHandler which
> will
> >> > > "implement" the interface - bound together through the
> >> > > PartialBeanBinding... is that right?
> >> > > Can I have multiple interfaces use the same partial bean binding,
> >> having
> >> > > all of them be "implemented" by the same handler?
> >> > >
> >> > > That should get me started :-)
> >> > >
> >> > > -David-
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Jason Porter
> >> > http://en.gravatar.com/lightguardjp
> >> >
> >>
> >
> >
> >
> > --
> > Jason Porter
> > http://en.gravatar.com/lightguardjp
>

Reply via email to