jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Padraic Hannon <...@wasabicowboy.com>
Subject Re: [OCM] JPA support
Date Wed, 06 Feb 2008 18:31:44 GMT
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



Mime
View raw message