jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: [OCM] JPA support
Date Thu, 07 Feb 2008 08:11:11 GMT
Hi Padraic,

JSR 283 defines support for parameters in query statements, which means we will 
eventually implement it.


Padraic Hannon wrote:
> 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

View raw message