From Day 1 (tm) the design of the PMNS tolerated more than one name
mapping to the same PMID (the strong analogy is hard links in a
Unix-like filesystem).
This was considered a "good idea" (also, tm) to support evolution of the
PMNS (my metric used to be a.b.c but now a.d.e.c makes more sense) and
common metrics that logically might appear in more than one group of
metrics, e.g. summary and detail) and because of the strong analogy to
hard links which are very useful.
But there was no compelling use case in the PMDAs we'd developed, and
the incidence of duplicate names mapping to the same PMID was considered
to be more likely a PMDA developer botch than an intended outcome.
So, we kept the duplicate names support in the code, but hid it below a
behaviour that made "no duplicates" the enforced default.
Recently I was playing with this in the context of a completely
unrelated bug triage, and tried extending the sample PMDA to include a
couple of duplicate names for two metrics.
Kaboom.
This does not work at all "as is". It can be made to work, but that
involves changing scores of source files ... the result is an ugly hack
hiding a git branch and I'm not going to commit that to the dev branch.
On reflection, I think there are 2 alternatives:
1. change the default behaviour to allow duplicates and strip out all
the "no duplicates" stuff, or
2. drop all pretence at supporting duplicate names and rip out the
associated non-working stuff.
Thoughts?
|