Would anyone care to comment on whether this should be an app responsibility or the responsibility of OJB?
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
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]>
