-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test failures with mysql and mariadb #597
Comments
The tests shouldn't assert equality of the SQL generated by GenQuery2 since it can change over time. Those assertions need to be removed or changed to assert specific character sequences appear in the result. |
I think one shouldn't have to assert those anyway. The only needed assertions should be that the results of a query match the expectations of the test, based on the conditions that were set up. |
Maybe I'm just repeating what @korydraughn has said, though ; ) |
That last test is also a subtle assumption about the database being postgres. This test failure spawned this issue, so I put the details over here: irods/irods#7930 We just need to tweak the test to change the assertion. However, I'm not sure what we want to assert here:
For postgres, we want to assert that only 1 result came back because there is only 1 data object with the name for which we are searching if the query is case sensitive (as it should be in this test). For mysql, the I'm thinking about splitting this one out into a separate issue and just commenting out this part of the test until we can decide on what to do with it. This does not seem like a blocker for 2.1.0 to me. Thoughts? |
As long as the PRC can demonstrate hitting the GenQuery2 API endpoint successfully, that's all that matters. Making assertions about the SQL returned by the GenQuery2 API isn't important for the PRC. If we must cover that case, then a few assertions like the following are good enough.
Given that GenQuery2 is experimental, it shouldn't block a release. |
Many of the tests in genquery2_tests.py include assertions on the specific SQL strings generated by GenQuery2. These assertions assume a Postgres database, causing the tests to fail on non-Postgres databases which are nonetheless supported by the iRODS server. These assertions have been replaced. This changes the Postgres-specific assertions in many of the genquery2_test tests to just assert that a table name is returned. We cannot assert the specific contents without reaching out to the server to detect the version and flavor of the database. Even then, the specific results may vary over time. Testing the generated SQL is more the responsibility of the GenQuery2 parser and API in the server anyway, so this test should just be asserting that a result that sort of looks like what we want is being returned by the library.
Many of the tests in genquery2_tests.py include assertions on the specific SQL strings generated by GenQuery2. These assertions assume a Postgres database, causing the tests to fail on non-Postgres databases which are nonetheless supported by the iRODS server. These assertions have been replaced. This changes the Postgres-specific assertions in many of the genquery2_test tests to just assert that a table name is returned. We cannot assert the specific contents without reaching out to the server to detect the version and flavor of the database. Even then, the specific results may vary over time. Testing the generated SQL is more the responsibility of the GenQuery2 parser and API in the server anyway, so this test should just be asserting that a result that sort of looks like what we want is being returned by the library.
The genquery2 tests have been fixed and are now passing for all the database flavors we support. The |
When running tests against the tip of main on an iRODS 4.3.3-ish server I saw the following tests fail when using a mysql 8.4 or mariadb 11.4 server for hosting the iRODS catalog:
irods.test.genquery2_test.TestGenQuery2.test_select
irods.test.genquery2_test.TestGenQuery2.test_select_and
irods.test.genquery2_test.TestGenQuery2.test_select_or
irods.test.genquery2_test.TestGenQuery2.test_select_with_explicit_zone
irods.test.query_test.TestQuery.test_files_query_case_sensitive
Here are the details:
I think the first few are pretty obviously postgres-dependent, and were introduced here: #555
I'm not sure about that last one. Maybe it has to do with case sensitive / insensitive search and defaults, or something.
Anyway, we should investigate this.
The text was updated successfully, but these errors were encountered: