-
1. Re: Transparent Object-Content-Mapping
My view on the matter is that ModeShape is effectively a JCR spec implementation and as such is essentially a library, not a datastore. In other words, just as HibernateORM is a JPA implementation which "facilitates" storage in a RDBMS, ModeShape is a JCR implementation which stores its data *somewhere* (the fact that it's using Infinispan is more of an implementation detail really).
I'm not sure what you mean by using the word "transparent", but IMO you should not attempt to mix JPA & JCR together in any way. If you want to use JCR then you have to use the JCR "language" (as defined by the spec). If you want to store data in a RDMS then you can use a JPA implementation, but I don't see anything in common between the two. You should choose one or the other. Attempting to interleave the 2 concepts (while probably doable from a technical perspective) will only cause you grief and pain down the line. For example, configure ModeShape to store data in a JDBC store and then look at that data - you will essentially see 3 columns in a table where the main data is stored as blobs. Such a structure would essentially be worthless when using a JPA library and attempting to retrieve data.
-
2. Re: Transparent Object-Content-Mapping
Hi Randall & team -- w my comment at https://issues.jboss.org/browse/ARTIF-683 as context...
what are your views on current best ways to transparently persist JPA/POJOs into JCR/ModeShape?
(For example, application usecases may want to use both JPA & JCR APIs onto the same Modeshape REPO; potentially with content from each side participating in the same graph.)
I agree with Horia -- there really isn't a good use case for mixing JPA and JCR. They both try to solve a similar problem in very different ways. Try to figure out which one suits your needs better, and use that one technology.
JPA, HibernateORM, using JCR-SQL2 to Modeshape as datasource?
No, this is not possible. ModeShape does provide a JDBC driver to allow clients to submit JCR-SQL2 queries, but they are just queries. You cannot update data this way. Besides, when the data is changed, the query results will change, and putting JPA objects on top of that will be very expensive and quickly get out of date.
Again, please don't try to mix JPA and JCR.
Anything more transparent, JPA-standard, and Modeshape-friendly/JBoss-centric than Kobee1203/jcrom · GitHub ?
I've never been a fan of JCR object mappers, since they basically take away many of the useful features of JCR, especially the schema flexibility. JCR is also very session-oriented, so any object mapping layer is going to add complexity and overhead.
Also, if necessary, how to tune to improve space/time efficiencies?
Such as hinting/tuning parameters to enable ISPN's cache store to leverage underlying DB (potentially, relational) strengths?
Infinispan is what it is, and there really isn't going to be a way to tune/hint it to leverage more of the underlying database. Infinispan already has query and storage support for annotated Java objects, but ModeShape does not use this feature (and cannot with a tremendous amount of work).