I was digging into the Parfait code on the train journey home (hope I don't
miss my stop) and wondering whether a newer version of Parfait might just
_always_ right identifiers in the new place. If it's going to have to be
changed to mark it's support for the new v2 version flag, it may as well just
encode all identifiers in the one spot. The reader of this (pmdammv) can just
do the heavy lifting identifying when to convert or not.
> On 29 Jun 2016, at 3:35 PM, Nathan Scott <nathans@xxxxxxxxxx> wrote:
>
> 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>
|