Attributes¶
As mentioned in the object handles chapter (see Object Handles) there currently (saf-1.2.0) exist two styles
of handles: “old” handles and “new” handles. For each “old” object class there are functions to put
(saf_put_XXX_att) and get (saf_get_XXX_att) attributes, as well as generic forms of these functions
(saf_put_attribute and saf_get_attribute) which operate on any object type but do not provide rigorous
compile-time type checking. The “new” object classes use only saf_putAttribute and saf_getAttribute,
which employ compile-time and run-time type checking.
There is an important limitation to the attributes interface in SAF. First and foremost, it should be clearly understood that there is no expectation that any data stored in attributes be shareable. If there is any expectation that any software other than the writer of the attributes should be sensitive to and/or aware of the data stored in them, the data should not be stored in attributes. If for some reason, your client is unable to model important features of the data without encoding something into attributes, then the current implementation of this data model is failing.
By convention, attributes whose names begin with a dot (“.”) are read-only. Thus, a client may create and initialize a new attribute whose name begins with a dot, but thereafter any client operating on the database can only read the value of that attribute.
Issues: Each attribute has its own HDF5 dataset in the SAF file. For a SAF__EACH mode call, we need to loop
creating num_procs datasets.
Also, performance of attribute access is likely to be poor, particularly in parallel.