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 <andru..bjectstyle.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 <ar..aniatis.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
This archive was generated by hypermail 2.0.0 : Thu Mar 04 2010 - 07:30:24 EST