rossi
Jakob Braeuchi wrote:
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]>
