Exposing and saving the Query Validity in the query object

[A-EbrahimRSA]

I am wondering the value add and complexity of having the query validity exposed on the query object itself at a high level/on a per rule basis similar to how disabled & muted are currently handled.. I would like to run some external API calls and logic but only when the query itself is valid.

I would like to try and ensure on the client-side, as far as I can, that the query is first syntactically valid(using the built in validators). Thereafter I can semantically/contextually check its validity in the backend afterwards. Being able to see the query validity would enable be to "watch" this with a useEffect and fire API calls accordingly.

To provide some further context, I did try using the defaultValidator(query) as a rough means to test for validity however, this is not a very foolproof solution.

I have found some more success in using formatQuery(query, { format: 'sql', fallbackExpression: 'Failed' }).

Essentially, I am taking advantage of the fact that the formatQuery method has some type of internal query validity checks and I am using this to check for the query validity. If this could be exposed as a callable method, that would be great.

[jakeboone02]

Sorry it took me so long to respond to this. Have a look at this PR:

• Add "diagnostics" export format #1018

It adds a "validation" export format that augments a copy of the query object with per-rule and per-group validation results.

Does that address your requirement?

[jakeboone02]

The only formats it might make sense for are "json" and "json_without_ids", and those produce strings for a more narrow purpose. This one creates an object which can be JSON.stringify'd if desired, but retains the object-ness of the query.

I'm considering a broader scope for this new format, with potentially more annotations than just validation results. Might call it "diagnostics" or something like that. I don't really know what I'd add at this point, just trying to think about possibiliites.

[A-EbrahimRSA]

Yeah okay, I'm hearing you out that we should maybe be separating some concerns here and not polluting those other exports without a strong reasoning.
I do like your idea of making this a "diagnostics"/"extra-metadata" style export so that it can be more granular and detailed but as mentioned not pollute a raw query export which is more valid for actual sql/mongodb/etc ... usage.

[jakeboone02]

I refactored the "validation" export format in #1018 to "diagnostics". The query property of the result is essentially the same as the full result from before: an annotated query object. But now it also has some other information.

[A-EbrahimRSA]

Looks good, I also like your approach of having an aggregated stats attribute, instead of having to potentially traverse the tree.

[jakeboone02]

It'll be in the next release.