Re: AW: orderby on write

[Phil Warrick]

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.

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