Hi guys,
Paul mentioned today that another Aconex project came across the
relatively small MMV metric name length limit. The following is
one way we could tackle that with some relatively simple changes
to pmdammv(1), while maintaining full backward compatibility.
The fundamental problem is that the "on-disk" metric and instance
types for MMV encode the names in a 64 byte character array. So,
I'm suggesting we support an optional (non-default) v2 MMV format
which would be exactly the same as v1 except that metric/instance
structures could specify the offset to a mmv_disk_string_t for the
name (instead of embedding it directly).
If a metric/instance name is presented that is too large to fit in
v1 format, the client library could transparently switch to using
v2 format and continue on.
In order to easily and unambiguously distinguish the new structure
types on-disk we would use new table-of-contents entries for each;
see the attached mmv(5) patch for struct layout details.
This change would affect pmdammv(1), mmvdump, the perl and python
wrappers, Parfait, and the new Go project as well. But, none are
*required* to support it (v1 format is essentially the same & will
continue to be supported indefinitely).
cheers.
--
Nathan
mmv.5.patch
Description: Text Data
|