@zhuangchong @break60 please take a look UI.thx

@chengshiwen @CalvinKirs

LIMIT limits the number of rows in a SQL query, and displayRows limits the number of rows that a log can print.
Isn't the number of queries the number of items to print?

@chengshiwen @CalvinKirs

LIMIT limits the number of rows in a SQL query, and displayRows limits the number of rows that a log can print.
Isn't the number of queries the number of items to print?

A user can choose not to send mail, so printing a few query results into the log is a good way. The variable displayRows is limited to less than 100, in order to avoid that the number of logs is too large.

For sending mail, the number of rows of query results sent can be larger, for example <= 10000

SonarCloud Quality Gate failed.

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

0.0% Coverage
0.0% Duplication

@chengshiwen @CalvinKirs

I wondered if this would make it more user-friendly,

SQL query result display has the email and log printing, on the front page for users to choose more the result display, set up the article a SQL query number limit parameters, the user can select only the log printing way, also can only choose mail way, also can also choose one of two ways (choice is at the same time may produce a large amount of data, this can agree)
In addition, I choose two display methods of log printing and email sending at the same time. I feel that the data can be viewed in either way many times at a time. Why should I view the data in both ways at the same time?

我想了一下这样调整会不会对用户更友好一些，
sql查询结果展示方式有邮件发送和日志打印，在前端页面可供用户进行多选结果展示方式，设置一个sql查询条数限制参数，用户可以只选择日志打印方式,也可以只选择邮件发送方式,也可以同时选择两种方式（同时选择的时候就是可能会产生很大的数据量，这个可以认同）

并且同时选择日志打印和邮件发送两种展示方法，我感觉多次一举，在任何一种方式都可以查看数据，为什么要两种方式同时查看？

@zhuangchong You can start a discussion in the dev email, and realize this improvement according to the idea you mentioned, not on this 1.3.6-prepare. The current pr is a cherry-pick from dev, and this improvement is the result of the previous discussion on March 17.

@zhuangchong You can start a discussion in the dev email, and realize this improvement according to the idea you mentioned, not on this 1.3.6-prepare. The current pr is a cherry-pick from dev, and this improvement is the result of the previous discussion on March 17.

ok, no problem.