NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
> I agree with Russ. A creation-sequence-number should be as
> information-free as possible. Same as an OID. Attributes like
> time-of-creation can be saved in some other form.
>
> Mike
>
> At 11:28 AM 11/12/2003, Russ Rew wrote:
> >Quincey,
> >
> > > My current idea is to add a "creation time" piece of metadata to each
> > > object as it is created in the file, and then the H5Giterate() call (or
> > > something resembling it) could choose whether to use creation times or the
> > > object names (or last modification times, etc.) as the method of
> > indexing the
> > > objects to iterate over. Fairly simple and straightfoward, I think...
> >
> >Even simpler would be a "creation sequence number" piece of metadata.
> >This would just be an integer that incremented for each new HDF5
> >object, or maybe several such sequences for different kinds of
> >objects.
> >
> >There are some advantages of sequence numbers over times:
> > - you don't have to worry about clock resolution and the possibility
> > that creation times of two objects are equal
Hmm, we use the gettimeofday() routine, which returns values in
microseconds, so this probably would not be too much of an issue, but I admit
it certainly is possible.
> > - you can use gaps in the sequence numbers to tell that objects have
> > been deleted, something not possible with times
I wasn't planning on exporting this information to the user (just using
for iterating over the objects in a group), so I'm not certain if this matters.
> > - adding 1 is cheaper than the system call necessary to access the
> > system clock
True, but both are minor compared to the cost of disk I/O involved, I think.
> > - in distributed systems, there is not necessarily a well-defined
> > time ordering for events (only a partial ordering)
This may be an issue.
> >I don't foresee any need for knowing the actual creation time of a
> >netCDF-4 object, but if there are other applications for this kind of
> >information, than feel free to ignore this suggestion ...
Hmm, I think there may be some issues with a creation sequence number also:
- The "last number issued" will need to be stored in the file (unlike
creation times).
- Should it be local to the group, or global to the file? There are
pro's and con's to both:
Global:
- Pro: One number to track for file
- Con: May have contention for updating this number in a
parallel environment.
- Con: Faster to roll over than a sequence number per group.
- Con: Sequence numbers in one group will have gaps, if
objects are created in other groups, which does not
imply objects were deleted in the group.
Local:
- Pro: More consistent numbering within one group than a
sequence number per file.
- Con: May have contention for updating this number in a
parallel environment.
- Con: A new piece of metadata to update with every object
created in a group.
I guess I would tend toward a local (i.e. per group) sequence number. How's
that sit with people?
Quincey
netcdf-hdf archives: