hi phil,
there's another feature that helps keeping relationships sorted:
'refreshRelationship'.
when refresh="true" the relationship is refreshed (reloaded) for objects
found in the cache.
<collection-descriptor
name="konti"
orderby="saldo"
sort="ASC"
element-class-ref="brj.ojb.Konto"
proxy="true"
>>> refresh="true"
hth
jakob
----- Original Message -----
From: "Phil Warrick" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Thursday, November 21, 2002 4:02 PM
Subject: Re: orderby on write
> Hi Thomas,
>
> But by giving OJB the sort attribute/column in repository_user.xml it
> has all that is required to manage the sort. It does know the order
> semantics; it's just that currently it doesn't enforce it on write.
>
> Phil
>
> Mahler Thomas wrote:
> > 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]>
>
>
>
> --
> 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]>
