Perhaps the first place to start would be to refactor the query
implementation to allow for more JDBC like semantics in terms of
setting query values. This would give us the ability to map to the jpa
query mechanism and allow us to have "named" queries.
For example:
SELECT * FROM my:type WHERE my:title= ?
We should be able to say setString(1, 'foo') or setString("my:title",
"foo"). The problem comes when you have multiple strings with the same
name, for example:
SELECT * FROM my:type WHERE jcr:path LIKE '/some/nodes/%' AND NOT
jcr:path LIKE '/some/nodes/%/%'
One could not call seString("jcr:path", ...) since there are two of
those in the where clause. In this case only numbers work. With JCR I
could see these sort of issues popping up all over the place. Any ideas?
On Feb 6, 2008, at 9:54 AM, Padraic Hannon wrote:
I've started to look into doing this and:
1) javax.persistence.Query doesn't really map well to either the OCM
query class nor to the OCM filter class I think that both classes
would have to be heavily refactored or replaced by an implementation
of the JPA Query class.
2) javax.persistence.EntityManager maps more cleanly, however, given
that one needs to have the ability to create queries using EJB QL we
would have to implement some sort of EJB QL parser to translate to
sql or xpath which would be a bit of a pain
I am sure there are more details I haven't dug up. If JPA is super
important we could start working on this as I think there are
advantages for making JCR usage more widespread (it would be nice
for people to be able to move existing apps to this new paradigm as
I think it has benefits in terms of simplifying object - data store
mapping).
-paddy
