my thoughts are we could generate a comparator on the fly and use it to sort the
collection, it would definitely be done in the code, not in the db, that's why it
would only work for getby collection and not getby iterator.
we would store the field they wanted to sort on and use that reflectively to sort like
this:
Collections.sort(this, new ReflectiveComparator()
{
public int compare (Object o1, Object o2)
{
// do all the stuff to get the method reflectively on both the objects
return (o1ReflectiveMethodReturnValue.compareTo(o2ReflectiveMethodReturnValue);
}
}
);
obviously there is a little bit more to it than that, since this will only work for
types that have Compare implemented, but it could be made to work for all types where
it makes sense, since it has to follow the rules of db sorting.
anyway, this would just be a convenience for the user as they could easily write the
sort code themselves.
m
-----Original Message-----
From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 23, 2003 8:50 AM
To: OJB Users List
Subject: Re: Order by across extents and question about materialization
hi matthew,
who would do the sorting for getCollectionByQuery ? imo this has to be
done in the code not in the db.
jakob
Matthew Baird wrote:
>I've put some thought into the sorting across extent problem, and while I think it's
>solvable pretty easily for a getCollectionByQuery, it's not as easy to solve in a
>getIteratoryByQuery situation.
>
>I think it would be confusing to present two different behaviours.
>
>order by on extents mapped to the same table will work, however.
>
>-----Original Message-----
>From: Jakob Braeuchi [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, January 22, 2003 11:14 AM
>To: OJB Users List
>Subject: Re: Order by across extents and question about materialization
>
>
>hi chris,
>
>you're right extents are handled by separate queries (one sql for each
>concrete extent) so sorting is a problem here.
>the second problem can easily be solved by using the
>PersistentFieldPropertyImpl instead of the default. see
>PersistentFieldClass= in ojb.properties.
>
>hth
>jakob
>
>Chris Rossi wrote:
>
>
>
>>Part I: The use of 'order by' with collections containing members of
>>differing type.
>>
>>Howdy, I've noticed the following. Let's say we have a class
>>structure that looks kind of like this:
>>
>><class-descriptor
>> class="Mamma">
>> <collection-descriptor
>> name="children"
>> element-class="Child"
>> orderby="index"
>> sort="ASC"
>> >
>> <inverse-foreignkey field-id-ref="2"/>
>> </collection-descriptor>
>></class-descriptor>
>>
>><class-descriptor
>> class="Child">
>> <extent-class class-ref="BoyChild"/>
>> <extent-class class-ref="GirlChild"/>
>></class-descriptor>
>>
>><class-descriptor
>> class="BoyChild">
>></class-descriptor>
>>
>><class-descriptor
>> class="GirlChild">
>></class-descriptor>
>>
>>For brevity I've left out fields in above, but assume all objects have
>>an 'id' feild and all Child objects also have 'parentId' and 'index'
>>field. Where 'index' is used to maintain an ordering on a collection
>>of Children.
>>
>>What I've found is that when the Children are a mix of types, ie mix
>>of BoyChildren and GirlChildren OJB fails to order them correctly.
>>Instead of the entire group being sorted by index, what you get back
>>is all of the boys in the group followed by all of the girls. I
>>assume this is because under the hood the 'order by' is being used in
>>the two seperate SQL queries to get children but it hadn't occurred to
>>anyone yet that it would be necessary to do sorting on the larger
>>collection in the event that a collection contains objects of
>>different types and residing in different tables.
>>
>>Part II: Materialization question related to above
>>
>>While using OJB 0.9.7 I had worked around the problem above by adding
>>a sort to the setter method on a collection. ie:
>>
>>public class Mamma {
>> public void setChildren( List children ) {
>> this.children = new ArrayList( children );
>> sortByIndex( children );
>> }
>>}
>>
>>Now that I'm in the middle of an upgrade to 0.9.9.1 I'm finding that
>>my workaround no longer works. For testing purposes I've changed the
>>above to:
>>
>>public class Mamma {
>> public void setChildren( List children ) {
>> throw new RuntimeException( "Am I being called?" );
>> /*this.children = new ArrayList( children );
>> sortByIndex( children );*/
>> }
>>}
>>
>>What I've discovered is that the setChildren() method is not being
>>called. And yet the object materialized by OJB contains children.
>>I'm kind of stumped as to how this can be occuring. What is the magic
>>that is causing this to happen? Are any setter methods for
>>collections being called during materialization? For that matter are
>>setter methods for fields being called during materialization? And if
>>no for either, how is an object materialized then?
>>
>>chris rossi
>>
>>
>>--
>>To unsubscribe, e-mail:
>><mailto:[EMAIL PROTECTED]>
>>For additional commands, e-mail:
>><mailto:[EMAIL PROTECTED]>
>>
>>
>>
>>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
