Skip to content

Commit 388ad3d

Browse files
committed
[_707,_768] README sections
1 parent ba3c682 commit 388ad3d

File tree

1 file changed

+61
-0
lines changed

1 file changed

+61
-0
lines changed

README.md

Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -832,6 +832,67 @@ of create and modify timestamps for every AVU returned from the server:
832832
datetime.datetime(2022, 9, 19, 15, 26, 7)
833833
```
834834

835+
Disabling AVU reloads from the iRODS server
836+
-------------------------------------------
837+
838+
With the default setting of reload = True, an iRODSMetaCollection will
839+
proactively read all current AVUs back from the iRODS server after any
840+
metadata write done by the client. This helps methods such as items()
841+
to return an up-to-date result. Changing that default can, however, greatly
842+
increase code efficiency if for example a lot of AVUs must be added or deleted
843+
at once without reading any back again.
844+
845+
```
846+
# Make a metadata view in which AVUs are not reloaded, for quick update:
847+
non_current_metadata_view = obj.metadata(reload = False)
848+
for i in range(10):
849+
non_current_metadata_view.add("my_key", "my_value_"+str(i))
850+
851+
# Force reload of AVUs and display:
852+
current_metadata = obj.metadata().items()
853+
from pprint import pp
854+
print(f"{current_metadata = }")
855+
```
856+
857+
Subclassing iRODSMeta
858+
---------------------
859+
The keyword option `iRODSMeta_type` can be used to set up any iRODSMeta
860+
subclass as the translator between native iRODS metadata APIs
861+
and the way in which the AVUs thus conveyed should be represented to the
862+
client.
863+
864+
An example is the `irods.meta.iRODSBinOrStringMeta` class which uses the
865+
`base64` module to "hide" arbitrary bytestrings within the `value` and
866+
`units` attributes of an iRODS metadata AVU:
867+
868+
```
869+
from irods.meta import iRODSBinOrStringMeta as MyMeta
870+
d = session.data_objects.get('/path/to/object')
871+
unencodable_octets = '\u1000'.encode('utf8')[:-1]
872+
873+
# Use our custom client-metadata type to store arbitrary octet strings
874+
meta_view = d.metadata(iRODSMeta_type = MyMeta)
875+
meta_view.set(m1 := MyMeta('mybinary', unencodable_octets, b'\x02'))
876+
877+
# Show that traditional AVU's can exist alongside the custom kind.
878+
irods.client_configuration.connections.xml_parser_default = 'QUASI_XML'
879+
meta_view.set(m2 := MyMeta('mytext', '\1', '\2'))
880+
881+
try:
882+
# These two lines are equivalent:
883+
assert {m1,m2} <= (all_avus := set(meta_view.items()))
884+
assert {tuple(m1),tuple(m2)} <= all_avus
885+
finally:
886+
del meta_view['mytext'], meta_view['mybinary']
887+
```
888+
889+
Whereas the content of native iRODS AVUs must obey some valid text encoding as
890+
determined by the resident ICAT DB, the above is a possible alternative - albeit
891+
one semantically bound to the local application that defines the needed
892+
translations. Still, this can be a valid usage for users who need a guarantee
893+
that any given octet string they might generate can be placed into metadata without
894+
violating standard text encodings.
895+
835896
Atomic operations on metadata
836897
-----------------------------
837898

0 commit comments

Comments
 (0)