Although not using ML,  mutation testing of existing test queries could
help catch additional parsing / planning issues. By coincidence I can
across the link below which could be conceptually relevant to this topic,
(although the code / implementation may not directly be)

https://in2test.lsi.uniovi.es/sqlmutation/?lang=en

Regards

Andrew

On Fri, 26 Apr 2019, 19:36 Vladimir Sitnikov, <[email protected]>
wrote:

> Let me post a couple of links I've came across today (it comes out of this
> Twitter thread:
> https://twitter.com/backendsecret/status/1121290210464034816
> ):
>
> https://github.com/alexknvl/fuzzball -- it is a machine learning driven
> fuzzer for Scala which identifies quite a few bugs in Scala compiler.
>
> The beauty of ML is we don't need to somehow declare the grammar, but it
> can just learn from lots of samples.
> I've no idea if that would play well for SQL (we need to declare metadata
> somehow), however it might still work somehow.
>
> Then there's https://github.com/cretz/javan-warty-pig a fuzzer + bytecode
> agent to trace execution (it remembers the taken paths, so it distinguishes
> "different" executions.
>
> https://github.com/alexknvl/tracehash -- a library that produces short
> summaries for exception stacktraces.
> Those signatures might be a good aid for "stackoverflow-guided-development"
> (== we might want to print stacktrace signatures by default for Calcite
> exceptions).
>
> Vladimir
>

Reply via email to