GeezerVison

Thanks, that's great! Some high-level comments first:

• for the SQLQueryError, this looks quite similar to ExpectedErrors. Do we really need this class or can we combine these classes?
• for statements like UPDATE, DELETE, and ALTER TABLE, do you think we can use and extend the generator classes rather than implementing the logic in the DQE oracle?

Thanks, that's great! Some high-level comments first:

• for the SQLQueryError, this looks quite similar to ExpectedErrors. Do we really need this class or can we combine these classes?
• for statements like UPDATE, DELETE, and ALTER TABLE, do you think we can use and extend the generator classes rather than implementing the logic in the DQE oracle?

Regarding the SQLQueryError and ExpectedErrors classes, while they do share some surface-level similarities, I think it's important to highlight that their purposes and usage patterns are quite different in practice:

• SQLQueryError is specifically designed to represent actual errors returned by the database, with structured fields like error level, code, and message. It plays a crucial role in DQE logic to distinguish between different types of errors returned by statements such as UPDATE, SELECT, or DELETE.
• On the other hand, ExpectedErrors serves as a declarative mechanism for defining acceptable errors during testing, primarily relying on substring or regex-based matching. It does not require the same level of structural detail as SQLQueryError.

Given these differences, merging them into a single class could lead to confusion, increased coupling, and reduced clarity in terms of responsibility separation. I believe keeping them separate helps maintain a clean architecture and supports better extensibility in the future.

That said, if you have any alternative suggestions or design ideas on how we can better organize this part of the code, I’d be more than happy to discuss them further. Thanks again for your thoughtful feedback! @mrigger @JensonSung

I think current implementation is good but specialized for DQE method.

Thanks, that's great! Some high-level comments first:

• for the SQLQueryError, this looks quite similar to ExpectedErrors. Do we really need this class or can we combine these classes?
• for statements like UPDATE, DELETE, and ALTER TABLE, do you think we can use and extend the generator classes rather than implementing the logic in the DQE oracle?

First, revising ExepctedErrors like SQLQueryError to provide a structured information may help ease to identify errors compared to a string-formed information. While DQE does not distinguish which error is expected but compare whether errors are consistent. A clear name could be required.
Second, it seems that every kind of statements like update and delete deserve a proper generator, preparing for new testing methods.
These two improvements can be put on the agenda.

Given these differences, merging them into a single class could lead to confusion, increased coupling, and reduced clarity in terms of responsibility separation. I believe keeping them separate helps maintain a clean architecture and supports better extensibility in the future.

Okay, then let's leave them separate for now. I guess there is a conceptual commonality (both are about errors returned by the database system), but if that does not (yet) make sense at an implementation level, we could try to address this later.

Sorry for possible confusing. @sayJason is my another account. I try to use the same one. Any problem, @JensonSung

Good jobs @luliqwerty . LGTM. Happy to merge @mrigger .

Agreed, lgtm, thanks a lot!

I just noticed that when executing the tests, there seems to be an issue:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running sqlancer.dbms.TestMySQLDQE
java.sql.SQLNonTransientConnectionException: No operations allowed after connection closed.
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)

Could you check whether you can reproduce this locally? This subsequently also results in a crash.

I just noticed that when executing the tests, there seems to be an issue:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running sqlancer.dbms.TestMySQLDQE
java.sql.SQLNonTransientConnectionException: No operations allowed after connection closed.
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)

Could you check whether you can reproduce this locally? This subsequently also results in a crash.

This is an unexpected error, as the CI for the merge commit passed. The error indicates that the code is attempting to execute an SQL operation on a database connection that has already been closed. However, it seems that DQE did not perform this action. @mrigger @JensonSung

I just noticed that when executing the tests, there seems to be an issue:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running sqlancer.dbms.TestMySQLDQE
java.sql.SQLNonTransientConnectionException: No operations allowed after connection closed.
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:110)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:89)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:63)
	at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:73)

Could you check whether you can reproduce this locally? This subsequently also results in a crash.

This is an unexpected error, as the CI for the merge commit passed. The error indicates that the code is attempting to execute an SQL operation on a database connection that has already been closed. However, it seems that DQE did not perform this action. @mrigger @JensonSung

It seems to be a crash bug. I run DQE locally in SQLancer, which executes without such errors.

Could it be that the local version of MySQL and the one in the CI are different? If they are the same, perhaps it could be helpful to run for DQE a bit longer. It could be that it triggered a crash bug, as pointed out by @JensonSung.

Btw, it would also be great to add DQE as part of the documentation of SQLancer in the table of the main README.md.

Could it be that the local version of MySQL and the one in the CI are different? If they are the same, perhaps it could be helpful to run for DQE a bit longer. It could be that it triggered a crash bug, as pointed out by @JensonSung.

Sorry for the late message. The local MySQL has a different version. I try a bit longer time to run DQE, which runs well and does not report errors.