You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A customer reported an issue migrating their styles using Studio in order to use expression syntax. Their legacy filters contained an in statement that referenced duplicate values, for example:
This seems to be a valid legacy filter, however upon migration it fails validation for the newer syntax with error output GL JSON Invalid: Branch labels must be unique.
I propose that the convertInOp method to convert legacy filter syntax include a line to remove duplicate string or numerical values. This can only benefit users of this utility by easing migration from a looser validation requirement to a tougher one.
Design Alternatives
Alternatively, we could tighten legacy validations, but that would break lots of working maps. We could also surface a warning in GL when we detect duplicate filter values in legacy syntax, however this could be confusing as the filter would still be valid.
The text was updated successfully, but these errors were encountered:
* Demonstrate filter conversion outputting invalid match expression
* Filter duplicate values when outputting match expressions
* Use a sorting method less likely to blow up at big O
* Tighten up sort expression
Motivation
A customer reported an issue migrating their styles using Studio in order to use expression syntax. Their legacy filters contained an
in
statement that referenced duplicate values, for example:filter: [ 'in', 'parent_0', 'AA', 'AA', 'AB', 'AC', ... ]
This seems to be a valid legacy filter, however upon migration it fails validation for the newer syntax with error output
GL JSON Invalid: Branch labels must be unique
.I propose that the
convertInOp
method to convert legacy filter syntax include a line to remove duplicate string or numerical values. This can only benefit users of this utility by easing migration from a looser validation requirement to a tougher one.Design Alternatives
Alternatively, we could tighten legacy validations, but that would break lots of working maps. We could also surface a warning in GL when we detect duplicate filter values in legacy syntax, however this could be confusing as the filter would still be valid.
The text was updated successfully, but these errors were encountered: