[#709] preserve options in chaining obj.metadata(opt1=val1)(opt2=val2)

[d-w-moore]

In other words, setting opt2 = val2 does not reset opt1 back to its default value.

[korydraughn]

Looks good overall.

[d-w-moore]

Evidently it is still possible to fail here:

https://github.com/d-w-moore/python-irodsclient/blob/388ad3d858ebcc7be981d1c065a4dd57ffc066cf/irods/test/data_obj_test.py#L3317

The modify time turned out on this occasion to be one second later than the access time on a just-created replica open for write:

======================================================================
FAIL [0.216s]: test_access_time__issue_700 (data_obj_test.TestDataObjOps.test_access_time__issue_700)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/prc.rw/irods/test/data_obj_test.py", line 3317, in test_access_time__issue_700
    self.assertEqual(data.access_time, data.modify_time)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2025, 11, 29, 4, 12, 23, tzinfo=datetime.timezone.utc) != datetime.datetime(2025, 11, 29, 4, 12, 24, tzinfo=datetime.timezone.utc)

----------------------------------------------------------------------
Ran 302 tests in 319.841s

FAILED (failures=1, skipped=16)

@korydraughn any ideas why this might occasionally happen?

[d-w-moore]

Squashed , ready for review.

[alanking]

I am especially interested in the changes related to #768 given the milestone for that issue.

[korydraughn]

Evidently it is still possible to fail here:

https://github.com/d-w-moore/python-irodsclient/blob/388ad3d858ebcc7be981d1c065a4dd57ffc066cf/irods/test/data_obj_test.py#L3317

The modify time turned out on this occasion to be one second later than the access time on a just-created replica open for write:

======================================================================
FAIL [0.216s]: test_access_time__issue_700 (data_obj_test.TestDataObjOps.test_access_time__issue_700)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/prc.rw/irods/test/data_obj_test.py", line 3317, in test_access_time__issue_700
    self.assertEqual(data.access_time, data.modify_time)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: datetime.datetime(2025, 11, 29, 4, 12, 23, tzinfo=datetime.timezone.utc) != datetime.datetime(2025, 11, 29, 4, 12, 24, tzinfo=datetime.timezone.utc)

----------------------------------------------------------------------
Ran 302 tests in 319.841s

FAILED (failures=1, skipped=16)

@korydraughn any ideas why this might occasionally happen.

Hmm, I don't think the python test code is equivalent to the following C++ test code?

https://github.com/irods/irods/blob/1a5670d157ce932cc2888d74bb29c831e2db53ae/unit_tests/src/test_rc_update_replica_access_time.cpp#L312-L323

https://github.com/irods/irods/blob/1a5670d157ce932cc2888d74bb29c831e2db53ae/unit_tests/src/test_rc_update_replica_access_time.cpp#L689-L706

The C++ test code I linked to expects the replica to be in the intermediate state.

I think the problem with the python test is that the following call closes the data object, resulting in the close operation updating the mtime.

python-irodsclient/irods/test/data_obj_test.py

Line 3311 in 94b8594

data = self.sess.data_objects.create(

What you need to do is open (and create) a new replica and do your checks while the replica is open. Closing the replica is what causes the atime and mtime to desync.

[d-w-moore]

What you need to do is open (and create) a new replica and do your checks while the replica is open. Closing the replica is what causes the atime and mtime to desync.

Ah, you're right. I see. Will try it a different way.

[korydraughn]

What's the status of this PR?

[d-w-moore]

What's the status of this PR?

Looks like we are good. Need a squash, and perhaps a codacy review.

[korydraughn]

Looks good overall.

Just a few comments on the README.

[d-w-moore]

To this subject
We can now , in this PR, do the following :

d_bin_meta = d.metadata(iRODSMeta_type = iRODSBinOrStringMeta)
d_bin_meta.set ( 'key1', b'arbitrary-octets-\xe1\x80')

And later: d_bin_meta ['key1'] (or an object similarly conditioned, in another application perhaps ) automatically returns an iRODSBinOrStringMeta('key1',b'arbitrary-octets-\xe1\x80') AVU

At worst, it's the client lib doing too much.

At best, it smooths a path that Python2 folks hypothetically might have relied on in the past (since bytestrings and strings were the same back then).

[korydraughn]

This looks ready to me.

Squash to taste once the review comment is resolved.

[korydraughn]

I see a revert in the git history?
Was that planned/expected?

What's the status of this PR?

[d-w-moore]

I see a revert in the git history?
Was that planned/expected?

The revert was merely to remove an unrelated change, a commit that shouldn't have made it in....

[d-w-moore]

Squashed just now.

[korydraughn]

Okay. Please resolve the ruff-check/format reports.

The "Files Changed" page (diff) should highlight the lines reported by the ruff workflows. You can use that view with the github actions report.