openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Prud'hommeaux <mprud...@apache.org>
Subject Re: org.apache.openjpa.persistence.ArgumentException?
Date Wed, 27 Jun 2007 18:22:35 GMT

For the record, I think Patrick is correct. In "update" statements,  
the alias (i.e., "identification variable") is optional, but in  
"delete" statements it doesn't appear to be.

It is a little surprising that this error isn't being caught by the  
parser. It is doubly surprising that the statement works sometimes  
but not other times, but I think that it is technically illegal.



On Jun 27, 2007, at 5:01 AM, Patrick Linskey wrote:

> Ed said:
>> I can use this workaround, but just for argument's sake I didn't  
>> think
>> that an alias was required.  This had worked without an error using
>> another JPA provider (I'm sorry for saying that more than once...  
>> I'll
>> stop).  For this test, though, I'll go through the named queries and
>> add aliases to them.
>
> Craig said:
>> The Persistence specification describes the DELETE statement as:
>>
>> delete_clause ::=DELETE FROM abstract_schema_name [[AS]
>> identification_variable]
>>
>> So the identification variable and the AS keyword are both optional.
>
> JPA spec says (4.6.2):
>> All identification variables used in the WHERE or HAVING clause of  
>> a SELECT
>> or DELETE statement must be declared in the FROM clause, as described
>> in Section 4.4.2.
>
> I believe that the JPA spec only makes the identification variable
> optional for the case where someone is just running 'DELETE FROM
> Person', for example. I do not believe that the intention is to allow
> DELETE FROM Person WHERE firstName = 'foo', since all of the
> where_clause BNF is defined with identification variables.
>
> So, IMO, the other implementation is being overly-permissive, and
> OpenJPA is giving you a really poor error message.
>
> I'm no lover of requiring identification variables, but my feeling is
> that if the spec requires them, it'd be better for OpenJPA to require
> more compliance rather than less, since the syntax is not
> significantly more difficult. Or, if we decide that we should be more
> lenient, it's probably a good time for us to introduce a strictness
> flag so that people can choose their level of compliance.
>
> -Patrick
>
> On 6/26/07, Ed Hillmann <ed.hillmann@gmail.com> wrote:
>> On 6/27/07, Marc Prud'hommeaux <mprudhom@apache.org> wrote:
>> > Ed-
>> >
>> > > delete from CachedItem where repository=:repository and  
>> folder=:folder
>> >
>> > Hmm ... that doesn't look legal to me, since it doesn't have any
>> > alias. I'm surprised it even parses. What happens if you change  
>> it to:
>> >
>> >    delete from CachedItem x where x.repository=:repository and
>> > x.folder=:folder
>> >
>>
>> Hi.  I've tried it using the snapshot, and it still failed.  I also
>> had the same idea as you about using a query with an alias.  So  
>> when I
>> define the NamedQuery as
>>
>> delete from CacheItem i where i.repository=:repository and  
>> i.folder=:folder
>>
>> it works fine.  I did think of that, only because it performed the
>> same kind of query on another managed entity, but its named query  
>> used
>> an alias.
>>
>> I can use this workaround, but just for argument's sake I didn't  
>> think
>> that an alias was required.  This had worked without an error using
>> another JPA provider (I'm sorry for saying that more than once...  
>> I'll
>> stop).  For this test, though, I'll go through the named queries and
>> add aliases to them.
>>
>> I'll attach the log to this email as well, just so you can see what's
>> going on.  But I can work with the workaround (use an alias in the
>> query).
>>
>> I'd just like to mention that the feedback on this mailing list is
>> great.  I very much appreciate the help that everyone is providing.
>>
>> Thanks again!
>> Ed
>>
>
>
> -- 
> Patrick Linskey
> 202 669 5907


Mime
View raw message