cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: [jira] Updated: (CAY-477) Support for preordered relationships
Date Thu, 04 Mar 2010 12:53:35 GMT
I don't think it will conflict with EJBQL in any way.

On Mar 4, 2010, at 7:29 AM, Andrey Razumovsky wrote:

> 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 <andrus@objectstyle.org>
>
>> 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 <ari@maniatis.org>
>>>
>>> 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
>>>
>>
>>
>
>
> -- 
> Andrey


Mime
View raw message