cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Lamy <davel...@gmail.com>
Subject Re: Referencing ID fields in EJBQL
Date Fri, 04 Dec 2009 13:16:52 GMT
Thanks Andrus.  I had actually pulled the trunk and was toying around with
adding an hql-esque .id "magic" field that would automatically reference a
single PK using your synthetic PK ObjAttribute stuff.  I nearly had it
working when I started hitting the problem mentioned in my other post.  I
don't suppose you might have any insight into that one.. :-)  It's a much
more pressing problem for me at the moment.

Dave

On Fri, Dec 4, 2009 at 2:39 AM, Andrus Adamchik <andrus@objectstyle.org>wrote:

> Yeah, in 3.0 EJBQL is somewhat of an implant from the JPA world, so it
> lacks a few Cayenne conveniences. I am certainly in favor to add support for
> "db:" expressions in the future versions (and the patches are welcomed).
>
> For now the option is to map PK column as the object property. Other than
> exposing it to the world, this shouldn't have any side effects. Auto
> generation will still work, etc.
>
> Andrus
>
>
> On Dec 4, 2009, at 12:05 AM, Dave Lamy wrote:
>
>  Hello all--
>>
>> I am curious to know how (if possible) to reference a PK field using
>> EJBQL.
>>
>> I tried using the normal expression "db:" syntax but as I saw in the
>> source
>> this won't work.  EJBQLPathTranslator.processLastPathComponent() appears
>> to
>> assume that the last part of any path will reference either an
>> ObjAttribute
>> or an ObjRelationship, and will throw an IllegalStateException if neither
>> of
>> these are the case.
>>
>> I'd like to have access to the PK field for a couple of purposes.  One,
>> when
>> doing COUNT queries it is faster to do a COUNT(PK) than a COUNT(*).
>> Furthermore, I want to be able to essentially group aggregate function
>> results by objects, which would be impractical to do using the OBJECT(e)
>> notation, so the plan was to perform the group query using IDs and then
>> fill
>> in the results with objects on the way out.
>>
>> Since the call from processLastPathComponent() to
>> processTerminatingAttribute() just resolves into a DbAttribute and thus a
>> column name anyway, wouldn't it be rather simple patch to do a "db:" check
>> on the path component and presume a DB column name instead of an
>> ObjAttribute name?  I imagine I may be oversimplifying the situation, but
>> if
>> not and there is agreement on the method I don't mind doing the patch.
>>
>> Of course, if there is an alternative way to reference PKs that I'm
>> unaware
>> of please enlighten me :-).
>>
>> Thanks--
>> Dave
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message