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]>
