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 <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 - 08:00:34 EST