Keith Davidson wrote:
Hi John,
Thanks for your reply.
"An early design decision was to make Attributes immutable." - do you
mean only for the Java API? Or are you saying that NetCDF Attributes
are inherently immutable, and that the C API achieves it by rewriting
the entire file?
But yes, the ability to modify Attributes in Java would be useful to us.
This would be useful because we use various Attributes to flag certain
information about the data in the file. As the data is modified, the
info about the data changes. In some cases we should perhaps be using
Variables instead of Attributes, but it is too expensive to change due
to the amount of software we have that expects this format. And this
software was written in C, Fortran, PVWave etc which allowed
modification of Attributes. But now we are writing most new software in
Java and finding the lack of being able to modify Attributes a pain.
cheers,
Keith.
Here are some dirty details from Russ Rew:
<quote>
In the C, C++, and Fortran interfaces (and probably perl and Python
too), attributes are completely mutable, in that you can rewrite them,
rename them, delete them, change their type, or change whether they
are scalar or vector-valued. That's because, unlike variables and
dimensions, their is no separation between the declaration of
attributes and giving them a value. It's all done in a single
function call such as
nc_put_att_text (ncid, varid, name, len, string_val)
Furthermore, it's possible to change the value of an existing
attribute without being in "define mode", which just overwrites the
existing value just as with variable values, as long as the space
required for storing the attribute does not increase.
But if the space required for the attribute value or name increases,
you have to be in "define mode", and the file may get rewritten when
you leave define mode either to access data values or to close the
file.
Before netCDF 3.5, the file always got rewritten on leaving define
mode if the space for an attribute changed, even if it shrank or was
deleted. With version 3.5, the file only gets rewritten if there
isn't space in the header for the new expanded attribute values (or
longer name). Space can be reserved in the header for attribute
expansion with a call in the C library to one of the "underbar
underbar" functions such as nc__create(), or by creating a large
attribute and deleting it. This latter is kind of a kludge, but was
deemed necessary to support conventions such as the ever expanding
"History" global attribute.
When we did Java, the argument was that attributes should be used for things
like "units" that don't change. If you wanted something that changed,
such as the average, max, and min of a variable, that should instead
be stored in a variable instead of an attribute.
Harvey Davies has argued that you should not even use
attributes, just use variables for everything and use a naming
convention for the attributes associated with a variable or with
another attribute, e.g. the variable "temperature.units" for the units
of temperature.
</quote>
Anyway, we will consider how to improve the situation, but for now Im
afraid that in the Java library you have to get all the attributes right
at file creation time.
