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
aep.d recommends using CEL as the filter language. However, the naming of the fields themselves are either snake_case in the case of protobuf, or camelCase in the case of JSON. This means that the filter syntax will be different, depending on whether you are using protobuf or JSON.
This might become problematic, especially if one is trying to pass the filter query directly from a JSON-based frontend to a proto-based backend. We probably need to decide on one, and provide some example or instructions on how the translation would work.
I just think the decision to transform field names is a huge mistake. It has so many sharp edges, and almost no benefit at all. snake_case JSON already exists all over the place.
aep.d recommends using CEL as the filter language. However, the naming of the fields themselves are either snake_case in the case of protobuf, or camelCase in the case of JSON. This means that the filter syntax will be different, depending on whether you are using protobuf or JSON.
This might become problematic, especially if one is trying to pass the filter query directly from a JSON-based frontend to a proto-based backend. We probably need to decide on one, and provide some example or instructions on how the translation would work.
CC @hudlow
The text was updated successfully, but these errors were encountered: