Virtual-schema-shared-integration-tests provide generic integration tests.
Refactor this repository to use that library.

Summary

Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.3 through 1.25.0.

Users are recommended to upgrade to version 1.26.0 which fixes the issue.

CVE: CVE-2024-25710
CWE: CWE-835

References

• https://ossindex.sonatype.org/vulnerability/CVE-2024-25710?component-type=maven&component-name=org.apache.commons%2Fcommons-compress&utm_source=ossindex-client&utm_medium=integration&utm_content=1.8.1
• http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-25710
• https://lists.apache.org/thread/cz8qkcwphy4cx8gltn932ln51cbtq6kf

Situation

We have added a few new functions to the common part recently.
We need to check if the dialect can support them. The list of the new function capabilities to check is:

• FN_BIT_LROTATE -> missing in MySQL
• FN_BIT_RROTATE -> missing in MySQL
• FN_BIT_LSHIFT -> added
• FN_BIT_RSHIFT -> added
• FN_FROM_POSIX_TIME-> missing in MySQL
• FN_HOUR -> added
• FN_INITCAP -> missing in MySQL
• FN_AGG_EVERY -> missing in MySQL
• FN_AGG_SOME -> MySQL has ANY function but it's used only in WHERE clause
• FN_AGG_MUL_DISTINCT -> missing in MySQL
• FN_PRED_IS_JSON -> There is a function JSON_SCHEMA_VALID (https://dev.mysql.com/doc/refman/8.0/en/json-validation-functions.html#function_json-schema-valid), but this is not predicate. Mapping won't be implemented until we have integration test for predicates.
• FN_PRED_IS_NOT_JSON -> missing in MySQL
• FN_HASHTYPE_MD5 -> missing in MySQL
• FN_HASHTYPE_SHA1 -> missing in MySQL
• FN_HASHTYPE_SHA256 -> missing in MySQL
• FN_HASHTYPE_SHA512 -> missing in MySQL
• FN_HASHTYPE_TIGER -> missing in MySQL
• FN_AGG_MUL -> missing in MySQL
• FN_JSON_VALUE -> (introduced 8.0.21) https://dev.mysql.com/doc/refman/8.0/en/json-search-functions.html#function_json-value. I wouldn't add this as we don't check the source version
• FN_MIN_SCALE -> missing in MySQL
• FN_AGG_LISTAGG -> missing in MySQL
• FN_AGG_LISTAGG_DISTINCT
• FN_AGG_LISTAGG_SEPARATOR
• FN_AGG_LISTAGG_ON_OVERFLOW_ERROR
• FN_AGG_LISTAGG_ON_OVERFLOW_TRUNCATE
• FN_AGG_LISTAGG_ORDER_BY
• FN_AGG_COUNT_TUPLE -> missing in MySQL

Since 2023-06-02 for version 8.18.1 of Exasol database a Docker image is available on Dockerhub.

The current ticket therefore requests to update the integration tests of VSMYSQL to use version 8.23.0 as latest default version.

Please note sibling-tickets for all JDBC-based virtual schemas.

Customer had a problem because of --/ before the line

CREATE OR REPLACE JAVA ADAPTER SCRIPT SCHEMA_FOR_VS_SCRIPT.ADAPTER_SCRIPT_MYSQL AS

as SQL clients other then DB Visualizer might find the script body to send to DB incorrectly in this case.

Please consider adding a remark to the User guide that the comment ('--/') will is ONLY necessary for a DB Visualizer SQL client and not for others.

When reading data from virtual schema I get a converison-error from UTF8 to ASCII,. Reading directly from the jdbc-connection works though.

EXA_DB.VIRTUAL_JOINTDB_OFFICE> Select * from(
IMPORT FROM JDBC
AT MYSQL_JOINTDB_JDBC_CONNECTION
STATEMENT 'SELECT * from office.erstattungen_positionen limit 100')
[2022-11-16 10:13:59] 100 rows retrieved starting from 1 in 1 s 85 ms (execution: 1 s 53 ms, fetching: 32 ms)
EXA_DB.VIRTUAL_JOINTDB_OFFICE> Select * from virtual_jointDB_office."erstattungen_positionen" limit 100
[2022-11-16 10:21:58] [42636] ETL-3009: [Column=23 Row=0] [Charset conversion from 'UTF-8' to 'ASCII' failed [Invalid or incomplete multibyte or wide character]] (Session: 1749641517751205888).

On the Source-DB the charset is latin1 (yes i know :(, not my fault^^).

• com.google.protobuf:protobuf-java:jar:3.19.4 in test
  • CVE-2022-3171, severity CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion') (7.5)

Unify errors with error-message-builder.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in Apache Commons Compress.This issue affects Apache Commons Compress: from 1.21 before 1.26.

Users are recommended to upgrade to version 1.26, which fixes the issue.

CVE: CVE-2024-26308
CWE: CWE-770

References

• https://ossindex.sonatype.org/vulnerability/CVE-2024-26308?component-type=maven&component-name=org.apache.commons%2Fcommons-compress&utm_source=ossindex-client&utm_medium=integration&utm_content=1.8.1
• http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-26308
• https://lists.apache.org/thread/ch5yo2d21p7vlqrhll9b17otbyq4npfg
• https://www.openwall.com/lists/oss-security/2024/02/19/2

Section "Registering the JDBC Driver in EXAOperation" is outdated.

Driver registering should be described via uploading driver mysql-connector-j.jar and a file settings.cfg to bucketfs folder default/drivers/jdbc/, see user guide of VSPG.

Content (see IntegrationTestConstants.java#L19)

DRIVERNAME=MYSQL
JAR=mysql-connector-j.jar
DRIVERMAIN=com.mysql.jdbc.Driver
PREFIX=jdbc:mysql:
NOSECURITY=YES
FETCHSIZE=100000
INSERTSIZE=-1

Currently, the tests are disabled, since there are many test failures.
See https://github.com/exasol/virtual-schema-shared-integration-tests

Situation

Aurora is a hosted database on AWS that claims interface compatibility with MySQL and PostGreSQL. After supporting TS(9) in MySQL VS (#48) we should check if that also works with Aurora.

Dependencies

• #48

Acceptance Criteria

• Either a integration test proves that TS(9) works with Aurora too
• or documentation updated that it is not update

Situation

Lombok is more hassle than it's worth. We are removing it step-by-step from all our projects.

Acceptance Criteria

• Lombok removed
• All tests green

Hello,
In MySQL Dialect User Guide JDBC driver settings table contains row for "Name".
At least in Exasol 7.0.7 it is called "Driver Name":

You may also notice that "Main" in the same table needs to be changed to "Main Class".

some shopsystems like Shopware6 use binary16 columns to store UUIDs as IDs for all the entities and relations.
these can be read as typical uuid-strings in mysql twe following way:
LOWER(CONCAT( SUBSTR(HEX(id), 1, 8), '-', SUBSTR(HEX(id), 9, 4), '-', SUBSTR(HEX(id), 13, 4), '-', SUBSTR(HEX(id), 17, 4), '-', SUBSTR(HEX(id), 21) )) as id
At the moment these columns just get left out when importing the shop-db as a virtual schema.
is there anyway to make these columns availble as varchar-columns in the given format?
or at least as varchar-columns containing the hex-display?

Invert the capability definition just like with PostgreSQL

• org.yaml:snakeyaml:jar:1.29 in test
  • CVE-2022-25857, severity CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion') (7.5)
  • CVE-2022-38749, severity CWE-787: Out-of-bounds Write (6.5)
  • CVE-2022-38751, severity CWE-787: Out-of-bounds Write (6.5)
  • CVE-2022-38752, severity CWE-787: Out-of-bounds Write (6.5)
  • CVE-2022-38750, severity CWE-787: Out-of-bounds Write (5.5)

Situation

We need to support nanosecond timestamp resolution.

Acceptance Criteria

• An integration test against Exasol 8 proves that TS(9) is supported