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, ThomasPhil Mahler Thomas wrote:regression testsHi 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.>
Have a look atThanks, Phil Phil Warrick wrote:Hi all,
It is possible to specify an "orderBy" attribute specifiedas either:1) an attribute of the collection descriptor's element-class-ref OR
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
collection(please scan repository_internal.xml for "orderby"). cheers, Thomas2) an unmapped table column
Upon retrieval OJB transparently orders the materialized
above, theaccording to this attribute.application (i.e.
Upon write, the correct order is persisted only if the
not OJB) correctly manages the attribute as in 1) above.This means
that in the case of an insert, for example, some or allsibling elements
may need to have their order attribute changed, again, by the application. In the case of an unmapped column as in 2)
order is lost when the collection is written.transparency
Is this the intended behaviour? If so should there be more
on write to be symmetric with the read behaviour? Mycomments 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]>