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

Reply via email to