[
https://issues.apache.org/jira/browse/CALCITE-4612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Sitnikov updated CALCITE-4612:
---------------------------------------
Description:
A generator of random rels would be useful for testing:
a) Generate rel, write it down as SQL (ensures "Rel to SQL" does not fail),
parse it back (ensures parser works OK), plans the tree (ensures the rules do
not throw exceptions)
b) Generate rel, serialize with one of the adapters (e.g. serialize to
ElasticSearch).
c) Generate rel, and execute it with https://github.com/sqlancer/sqlancer (or
alike) approach to verify the results of the query. It might surface
**correctness** bugs in optimizer, not just NPEs
----
Open questions:
Q1) Which tables/columns should be used? It looks like we should start with
VALUES, and then we could add a random table/column generator.
was:
A generator of random rels would be useful for testing:
a) Generate rel, write it down as SQL (ensures "Rel to SQL" does not fail),
parse it back (ensures parser works OK), plans the tree (ensures the rules do
not throw exceptions)
b) Generate rel, serialize with one of the adapters (e.g. serialize to
ElasticSearch).
c) Generate rel, and execute it with https://github.com/sqlancer/sqlancer (or
alike) approach to verify the results of the query. It might surface
**correctness** bugs in optimizer, not just NPEs
> Fuzzer for RelBuilder
> ---------------------
>
> Key: CALCITE-4612
> URL: https://issues.apache.org/jira/browse/CALCITE-4612
> Project: Calcite
> Issue Type: Test
> Components: core
> Reporter: Vladimir Sitnikov
> Priority: Major
>
> A generator of random rels would be useful for testing:
> a) Generate rel, write it down as SQL (ensures "Rel to SQL" does not fail),
> parse it back (ensures parser works OK), plans the tree (ensures the rules do
> not throw exceptions)
> b) Generate rel, serialize with one of the adapters (e.g. serialize to
> ElasticSearch).
> c) Generate rel, and execute it with https://github.com/sqlancer/sqlancer (or
> alike) approach to verify the results of the query. It might surface
> **correctness** bugs in optimizer, not just NPEs
> ----
> Open questions:
> Q1) Which tables/columns should be used? It looks like we should start with
> VALUES, and then we could add a random table/column generator.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
