When updating compatibility, a vexing issue occurs where an update to Compatibility (although conceptually, that's all the update needs to touch) doesn't result in correct implementation if PmappingGroup.merge_next is not also updated. Moreover, which part of the code that needs to be updated isn't clear (you have to know what pd.merge does and how we use it), and if you forgot to update that part, AccelForge silently returns incorrect mapping that is caught only because we run evaluate_mapping afterwards.
I'm thinking of making the following update:
PmappingGroup.merge_next should ask Compatibility which columns should match (e.g., via a matching_symbols property).- Then, anyone updating Compatibility can also update the property.
- We could make it automatic by assuming that all symbols must match. In that case, we already have
Compatibility.symbols
My remaining question is this:
- is there ever a case where we don't want two
Compatibility to match in terms of the value of a symbol to join?
When updating compatibility, a vexing issue occurs where an update to
Compatibility(although conceptually, that's all the update needs to touch) doesn't result in correct implementation ifPmappingGroup.merge_nextis not also updated. Moreover, which part of the code that needs to be updated isn't clear (you have to know whatpd.mergedoes and how we use it), and if you forgot to update that part, AccelForge silently returns incorrect mapping that is caught only because we runevaluate_mappingafterwards.I'm thinking of making the following update:
PmappingGroup.merge_nextshould askCompatibilitywhich columns should match (e.g., via amatching_symbolsproperty).Compatibility.symbolsMy remaining question is this:
Compatibilityto match in terms of the value of a symbol to join?