[OCM] JPA support

[Padraic Hannon <pi...@wasabicowboy.com>]

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

Re: [OCM] JPA support

[Marcel Reutegger <ma...@gmx.net>]

Hi Padraic,

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

regards
  marcel

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
> 
> 
> 

Re: [OCM] JPA support

[Padraic Hannon <pi...@wasabicowboy.com>]

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