fix(AIP-160): move validation guidance to new section #1460
Conversation
noahdietz
requested review from
neomagus00 and
jskeet
and removed request for
neomagus00
|
|
||
| Schematic validation refers, but is not limited to, the following: | ||
|
|
||
| - Fields referenced in the `filter` **must** exist on the filtered schema |
There was a problem hiding this comment.
Did we have a notion of a sort of "logical" field, or do we require the use of functions for that?
There was a problem hiding this comment.
can you explain that a bit more? Hwat do you mean by "logical" field?
There was a problem hiding this comment.
Something that may not end up being exposed as an actual field, but has some sort of logical value. For example, if we had an expiry timestamp, there could be some sort of "expires less than one minute from now" that you might want to filter on. I suspect that in most cases, output fields would be fine, and functions cover other situations, but it's just something to consider.
There was a problem hiding this comment.
Ah yes I see what you mean. In my mind I refer to those as "virtual" fields. I believe that is what functions are for atm.
The only mention of what to do in the face of a non-compliant
filteris buried in a somewhat unrelated subsection. Furthermore, no explicit guidance is given as to how schematically invalid filters are handled in general e.g. referring to a field that doesn't exist, using a value that doesn't align with the field's type, etc.This moves that "non-compliant
filter==INVALID_ARGUMENT" to a dedicatedValidationsection and includes mention of some schematic validation.Internal bug http://b/383153119