jdiff should support multiple ref key anchoring about jdiff HOT 1 CLOSED

After analyzing the current code-base such pinning of the VRF key won't be possible without changing the current implementation of ref_key processing.

The proposal in this issue is to allow to use multi ref_keys like that:
"$*$.peers.$*$.*.*.[accepted_prefixes,received_prefixes,sent_prefixes]"
|-------------^
One for vrf one for peer IPs, but look where the peers key is pinned ... and yes this is a very intuitive way IMO.
However when you look at our unittest, for the same data structure when we want to assign the ref_key for peer IPs it's currently done like that:
"global.$peers$.*.*.ipv4.[accepted_prefixes,received_prefixes,sent_prefixes]"
|-----------^
Which returns this data:

[{'10.1.0.0': {'accepted_prefixes': 1000,
               'received_prefixes': 1000,
               'sent_prefixes': 1000}},
 {'10.2.0.0': {'accepted_prefixes': 1000,
               'received_prefixes': 1000,
               'sent_prefixes': 1000}},
 {'10.64.207.255': {'accepted_prefixes': 1000,
                    'received_prefixes': 1000,
                    'sent_prefixes': 1000}},
 {'7.7.7.7': {'accepted_prefixes': 1000,
              'received_prefixes': 1000,
              'sent_prefixes': 1000}}]

Conclusion:
Current implementation to pin the ref_key for peer IPs expects that the $$ markers are used on the preceding key/path element "peers" and not on the exact key location, like proposed in this issue.
If you look at vrf in this case global, that's the first key in the data structure and there is no preceding key to pin it.
To implement multi-ref_key support we need to change the current behavior.

The process would look like this:

• re-implement ref_key processing to stick to the element which in fact needs to be pinned.
• update ref_keys in unittests, output data should not change, only the ref_key markers will be moved right.

from jdiff.