Failed SQL generation when encountering invalid tokens for a table

[zhangysh1995]

Description:

If I have a table without int type columns, and the grammar uses _field_int, it will throw an error and exit directly:

Example:

zhangys@xxx:~/go/bin$ ./go-randgen gensql -Y ../src/github.com/pingcap/go-randgen/examples/functions.yy   --dsn "root:@tcp(127.0.0.1:3000)/test" -Q 50
2020/07/08 07:07:50 Cache database meta info...
2020/07/08 07:07:50 Cache database meta info ok, start generate sqls by yy
2020/07/08 07:07:50 load yy from ../src/github.com/pingcap/go-randgen/examples/functions.yy
2020/07/08 07:07:50 Fatal Error: there is no int fields

Expected behavior:

It should roll back to the rule expansion to choose another one, then proceed to normal generation.

Diagnosis:

Please check for the root cause

[cyliu0]

I don't really get it. Do you mean that we should not raise the error even if it's an illegal usage? I think this action is by design...

[zhangysh1995]

@cyliu0 This issue is quite old, I suppose I could convert it into a feature request.

The current assumption is that all tables should have the same schema to run gosql. This is the reason why error is raised as 2020/07/08 07:07:50 Fatal Error: there is no int fields.

I think it helps to remove this assumption and support diverse table scheme, to make gosql run a any given database.

[cyliu0]

Oh... I get your idea now... But some of our users may still need this. I got a quick solution to your request. Add an option to ignore the error or skip the check. Will this meet your requirement?

[cyliu0]

And we have a plan to improve this tool recently. You are welcomed to touch me on slack workspace TiDB Community if you have more enhancement requirements.

[zhangysh1995]

But some of our users may still need this.

I think to enable scan different table schema is not conflicting with scanning tables with the same scheme. The assumption is a special case of table schema, so may be it can be handled uniformly with different schema?