Hi Phil, > > > Hi again, > > Would anyone care to comment on whether this should be an app > responsibility or the responsibility of OJB?
OJB does the job.> > Thanks, > > Phil > > Phil Warrick wrote: > > Hi all, > > > > It is possible to specify an "orderBy" attribute specified > as either: > > 1) an attribute of the collection descriptor's element-class-ref OR Have a look at http://jakarta.apache.org/ojb/repository.html#collection-descriptor There is an orderby attribute on the collection-descriptor. You will find a sample of it's useage somewhere in the OJB regression tests (please scan repository_internal.xml for "orderby"). cheers, Thomas > > 2) an unmapped table column > > > > Upon retrieval OJB transparently orders the materialized collection > > according to this attribute. > > > > Upon write, the correct order is persisted only if the > application (i.e. > > not OJB) correctly manages the attribute as in 1) above. > This means > > that in the case of an insert, for example, some or all > sibling elements > > may need to have their order attribute changed, again, by the > > application. In the case of an unmapped column as in 2) above, the > > order is lost when the collection is written. > > > > Is this the intended behaviour? If so should there be more > transparency > > on write to be symmetric with the read behaviour? My > comments are based > > solely on my own limited experimentation and code perusal; > I would be > > interested to hear if there is more to the story. > > > > I would be happy to look into implementing this functionality if > > necessary and if others thought it was generally useful. > > > > Thanks, > > > > Phil > > > > > > -- > > 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]>
