[#746] establish default order for replicas listed by an iRODSDataObject

[d-w-moore]

The parent data object's modify_time and replica_status fields , as well as some others, actually pertain more to individual replicas.

#747 was an old PR meant to address the issue and contains much discussion as well.

On consideration, I think a minor release is the proper place to address this, and I'm doing it by

• setting a default sorter that for data_objects.get ( or anytime running the iRODSDataObject constructor) sorts replicas of the data object first by the replica-"goodness" and secondly by reverse chronology of the replica modify_time (ie most recent first.) The replica at array position [0] will then determine the values of the fields discussed above.
• deciding for the time being not to deprecate anything. yet. To me it makes natural sense to allow modify_time and replica_status to be accessed from the "head" object.

So, this PR replaces the old one, #747 , due to being new work and being based on top of source code conveniently ruff-formatted.

[korydraughn]

• setting a default sorter that for data_objects.get ( or anytime running the iRODSDataObject constructor) sorts replicas of the data object first by the replica-"goodness" and secondly by reverse chronology of the replica modify_time (ie most recent first.) The replica at array position [0] will then determine the values of the fields discussed above.

Keep in mind that for a minor release, we cannot change the behavior of any public APIs. If the default sorter results in the output being different, then that's a no go. The default sorter must mirror the original behavior.

• deciding for the time being not to deprecate anything. yet.

What are you referring to in regard to deprecation?

To me it makes natural sense to allow modify_time and replica_status to be accessed from the "head" object.

What does this mean?

[d-w-moore]

• setting a default sorter that for data_objects.get ( or anytime running the iRODSDataObject constructor) sorts replicas of the data object first by the replica-"goodness" and secondly by reverse chronology of the replica modify_time (ie most recent first.) The replica at array position [0] will then determine the values of the fields discussed above.

Keep in mind that for a minor release, we cannot change the behavior of any public APIs. If the default sorter results in the output being different, then that's a no go. The default sorter must mirror the original behavior.

• deciding for the time being not to deprecate anything. yet.

What are you referring to in regard to deprecation?

We'd discussed in the old issue/PR convo's whether we might not just deprecate the iRODSDataObject fields like replica status and modify_time that are really just a reflection of the corresponding attribute of replicas[0]

To me it makes natural sense to allow modify_time and replica_status to be accessed from the "head" object.

What does this mean?

Just that .replicas[0].FIELD is mirrored in .FIELD, but that is pretty natural.
I guess we could actually just make them properties, rather than duplicating the data. But that is low priority.

[d-w-moore]

@korydraughn - I'm fine with changing the default order back to sorting on replica number for this minor release, even if it will allow attributes such as dataObject.modify_time to continue to misrepresent the "information advertised" .... It's but a minor code change to allow the application writer to sort differently if they so desire....

[korydraughn]

We'd discussed in the old issue/PR convo's whether we might not just deprecate the iRODSDataObject fields like replica status and modify_time that are really just a reflection of the corresponding attribute of replicas[0]

Oh right. That still sounds like an acceptable approach.

Just that .replicas[0].FIELD is mirrored in .FIELD, but that is pretty natural. I guess we could actually just make them properties, rather than duplicating the data. But that is low priority.

I'm not yet convinced that is the proper approach. Feels like it should be handled via support functions which simplify the find-replica step.

Do instances of iRODSDataObject always have the list of replicas? If so, then they can sort/search the list of replicas for what they need. Perhaps that's how the iRODSDataObject constructor works in this PR?