cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Razumovsky <>
Subject Re: [jira] Updated: (CAY-477) Support for preordered relationships
Date Thu, 04 Mar 2010 12:29:22 GMT
I think that will be enough for now.
And what about EJBQL? Will it conflict with specification if we return
relationships already preordered? (although I haven't yet thought of how to
do it)

2010/3/4 Andrus Adamchik <>

> I agree with the query vs. relationship comparison. Unfortunately the
> mapping solution will correspond to a mapped query, vs. query created in the
> code.
> It is only easy to implement if we allow the list to go unordered on
> changes of its objects. Which I think is ok, as I mentioned earlier.
> Andrus
> On Mar 4, 2010, at 2:55 AM, Andrey Razumovsky wrote:
>  The problem is that explicit query allows orderings, while indirect (via
>> Artist.getPaintings()) does not (the same can be said about e.g.
>> prefetches
>> though). So, if I want some array to be sorted (which is quite often) I
>> have
>> to create queries for to-many orderings. Since I often use
>> reflection-based
>> invocations, I have to create new methods, like getOrderedPaintings(),
>> moreover, bother about caching the data. IMO the feature is easy to
>> implement (most is in the patch, actually) and worth it. Also note that
>> we've seen several same wishes on the user list
>> artist.getPaintings(Comparator/Ordering) is fine, but we can't generate
>> that
>> methods for every relationship, and more generic methods will lose things
>> like Java Generics advantages.
>> My vision is that this feature will be used for relationships that are
>> ordered is same way [by default] in every context - e.g. I want people to
>> be
>> sorted by name everywhere.
>> 2010/3/4 Aristedes Maniatis <>
>>  On 4/03/10 8:28 AM, Andrus Adamchik wrote:
>>>  Also here is a reason why I don't find ordering of relationships
>>>> particularly useful is that things like ordering are context dependent
>>>> ("context" in a general sense)... The same mapping can be used by
>>>> different UI frontends with different ordering requirements.
>>> Having a default ordering for ObjEntities defined in the model is what
>>> Rails does. Any time you fetch that entity, be it directly through a
>>> Query
>>> or via a relation, you get the results back with that ordering.
>>> Personally I don't see the point. Ordering in the database is very useful
>>> if you are paging the results. Or using a limit. But when following
>>> relations, neither of those things applies, so you may as well just do it
>>> in
>>> memory once you have the list returned.
>>> Perhaps a simplified notation might be useful though:
>>> artist.getPaintings(Comparator/Ordering)
>>> Ari
>>> --
>>> -------------------------->
>>> Aristedes Maniatis
>>> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
>> --
>> Andrey


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