Ah, now I get your point. > -----Ursprüngliche Nachricht----- > Von: Phil Warrick [mailto:[EMAIL PROTECTED]] > Gesendet: Donnerstag, 21. November 2002 15:45 > An: OJB Users List > Betreff: Re: AW: orderby on write > > > Hi Thomas, > > All these examples use a primary key as the sort attribute. I'm > interested in a sort order that can be modified over time, so using a > primary key is not a good idea. Another column dedicated to > the sort is > therefore required, and its the behaviour of OJB with respect to this > column that I'm referring to. Currently as far as I can see, > there is > not special OJB "orderby" logic during write. As I mention > below, the > best example where this is important would be when an element is > inserted into an ordered list, requiring renumbering of some > or all of > the sibling elements.
correct, this is not managed by OJB. From an OJB perspective this is application logic. OJB will simply store your objects "as is". OJB does not know your ordering semantics. So it can not know to perform the "renumbering". The orderby attribute is only used for maintaining order on loading objects. This does not require knowledge about the ordering semantics. cheers, Thomas > > Phil > > Mahler Thomas wrote: > > 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]> > > > > -- > 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]>
