At the moment, we have some members of the DatabaseObjectWriter hierarchy that restrict the features of the super classes, as in
https://github.com/exasol/test-db-builder-java/blob/main/src/main/java/com/exasol/dbbuilder/dialects/postgres/PostgreSqlImmediateDatabaseObjectWriter.java#L33

A class should extend another one if:

• the subclass is a superclass
• the subclass can do everything the superclass can

Extending a class restricting the super class is usually not a good idea, as it breaks the Liskov substitution principle and will eventually lead to a hierarchy hard to maintain, extend and change.

We should fix this.

Situation

Since the TDDB is a library that you usually include in your projects via Maven or Gradle, we need to deploy to the Central Repository.

Acceptance Criteria

1. Version 0.1.0 deployed on Central Repository

Add support for building SAP HANA test databases.

The database does currently not support R adapter scripts. For that reason, R should be removed from the list of possible languages for adapter scripts.

Add a flag to deleted DaabaseObjects that marks them as deleted and causes TDBJ to refuse operations on them

Situation

The current system privilege list contains only one entry: SESSION. We need more.

Acceptance Criteria

1. All privileges from listed on the DOC portal are supported.

The unified connection definition requires connections like:

CREATE OR REPLACE CONNECTION S3_CONNECTION
TO ''
USER ''
IDENTIFIED BY '{
  "awsAccessKeyId": "<AWS_ACCESS_KEY>",
  "awsSecretAccessKey": "<AWS_SECRET_KEY>",
  "awsRegion": "<SESSION_TOKEN>",
  "s3Bucket": "<BUCKET_NAME>"
}';

Currently, TDBJ can't create this connection since it can not create connections with a password but no username.

This project already uses the error-message-builder but only for a few Exceptions.

Acceptance Criteria:

All exceptions use error-message-buildr.

Situation

The first implementation comes without a user guide. This is required for completeness.

Acceptance Criteria

1. User guide exists.

Add a dialect for PostgreSQL.

Situation

We need this test framework in our row-level-security integration tests.

Acceptance Criteria

• Can create: Schema, Virtual Schema, Table, User, Connection
• Can fill: Table
• Can grant: SESSION, all object privilege types

Currently createTableBuilder is implemented in the AbstractSchema but not part of the public interface

for example for creating a table

https://sonatype.github.io/ossindex-maven/maven-plugin/

Most of the database objects are instantiated with and com.exasol.db.Identifier, as in https://github.com/exasol/test-db-builder-java/blob/main/src/main/java/com/exasol/dbbuilder/dialects/postgres/PostgreSqlUser.java#L18

Some other objects do the same but change the API, as in https://github.com/exasol/test-db-builder-java/blob/main/src/main/java/com/exasol/dbbuilder/dialects/postgres/PostgreSqlSchema.java#L18

This makes the API harder to use. We should unify this.

The PostgreSQL dependency has CVE-2022-21724, detected by dependabot. This is the issue ticket for the corresponding dependabot PR #92.

Currewntly the MySQL and PostgreSQL Identifier allow SQL injection:

System.out.println(MySQLIdentifier.of("test`, `asdf`, `other").quote());

--> `test`, `asdf`, `other`

Problem

We have an integration test for DB2 Virtual Schema. The test would be more readable if we use db-builder with DB2 dialect in the test.

It should be possible to drop objects using the CASCADE option.

just like for scripts

Problem

executeSqlFile() method didn't work with a file that contains a few SQL statements divided by ;.
Would be nice to parse such a file and execute it.

Add support for Oracle

Add an possibility to add an -agentlib:jdwp=transport=dt_socket,server=n,address=<HOST_ADDRESS> to the CREATE ADAPER SCRIPT

Situation

As a tester sometimes I want to replace existing database objects.

Acceptance Criteria

• Udfscripts, tables can be replaced

We can create all objects using CREATE OR REPLACE by default and in addition add api for the replacing existing ones.

Situation

In cases where you create transient database objects in test cases, you want to make sure that the are dropped after the test case.
The cleanest way to get rid of test-case-specific objects would be to initialize them in a try-with-resources and let Java clean them up. This also works if the test fails.

Acceptance Criteria

• Database objects that support drop() also implement AutoClosable

Add MySQL identifier validation according to
https://dev.mysql.com/doc/refman/8.0/en/identifiers.html

Situation

TDDB support Exasol User defined functions (UDF) object. But user guide does not mention it.

Acceptance Criteria

• Added short description and example of UDF creation to user guide

Situation

For the first set of functions requirements and design are still missing.

Acceptance Criteria

1. All existing functions covered in requirements and design

Situation

Sometimes you want to try out how your SQL scripts behave if you feed them parameters that contain single or double quotes.
While double quotes seem to work fine, single quotes produce an error.

script.execute(parameters)

Produces

syntax error, unexpected IDENTIFIER_LIST_, expecting ',' or ')' [line 1, column 114]

This is caused by the fact that the prepared statement does not use placeholders, so the parameters are not properly quoted. That results in constructs like this:

EXECUTE SCRIPT "REMOVE_USER_FROM_GROUP_SCHEMA"."REMOVE_USER_FROM_GROUP" ('THE_USER',  ARRAY('GROUP_A', 'CONTAINS'SINGLE_QUOTE', 'GROUP_C'))

Acceptance Criteria

• Script parameters are properly quoted.

Problem

The link in the pom file is broken:

Broken link: https://github.com/exasol/test-db-builder
Correct link: https://github.com/exasol/test-db-builder-java

Let bucketFsContent accept multiple jar files.

Example:

bucketFsContent("com.exasol.adapter.RequestDispatcher", "lib1.jar", "lib2.jar");

Situation

Sometimes you need to manipulate database objects in test that already exist. For example if they were created by your implementation and you need to modify them for a white-box test. Or if they are imported from a SQL file.

In those cases the TDDB must let you attach to these existing database objects. For starters we are covering scripts, but the concept can be expanded to other types too.

Acceptance criteria

• Users can get a control object for an existing script.

See CVE-2022-21724 in the PostgreSQL JDBC driver.

Add a drop() method to DatabaseObject

The method should drop the database object.

Current state:
It is only possible to insert data row by row. This is comparably slow.

Desired:
Fast insert method.

Add a method to truncate tables.

Situation

With the basic implementation we can create all kinds of adapter scripts. But especially for Java adapter scripts, a specialized builder could increase code compactness, readability and user convenience.

Acceptance Criteria

1. Convenience builder for Java Adapter scripts added.
2. Builder accepts JVM parameters (e.g. for configuring a debugger, profiler or SONAR agent)
3. Builder accepts JAR references
4. Builder accepts mail class reference

Situation

If you want to check whether your scripts produce the expected exceptions, it is more convenient to not have them wrapped in a runtime exception — or to be more precise a DatabaseObjectException.

Acceptance Criteria

1. Scripts can optionally be executed without wrapping the SqlException.

Situation

Currently the TDDB can create adapter scripts. But for testing the administration scripts in RLS we need support for creating LUA scripts too.

Acceptance Criteria

1. TDDB can create LUA scripts

Change the API for adding a debugger connection to a global configuration for JVM options.

Add a JUnit extension that isolates a test case. Isolates mean that all objects that were created during a test will be deleted afterwards.

Ideas for the API:

@TestDbBuilder
private static ExasolObjectFactory testDbBuilder = ...;

@Tests
void test(@IsolatedTestDbBuilder ExasolObjectFactory factory){
 factory.createSchema("test");
}

or

@TestDbBuilder
private static ExasolObjectFactory testDbBuilder = ...;

@Tests
@WithTestDbCleanup
void test(){
  factory.createSchema("test");
}

Expected behavior:

• TDB deletes the schema test after the test execution.
• Objects created in outside the test (for example in beforeAll) are not neleted

At the moment, every time we are instantiating a new object to be save in the database, we do the saving inside the constructor as in https://github.com/exasol/test-db-builder-java/blob/main/src/main/java/com/exasol/dbbuilder/dialects/postgres/PostgreSqlSchema.java#L21.
This might be dangerous as the objects are not fully created at that point, specially if we keep instantiating fields after this call.

At the same time, we are providing the user of the API a clear entry point for creating these objects (https://github.com/exasol/test-db-builder-java/blob/main/src/main/java/com/exasol/dbbuilder/dialects/postgres/PostgreSqlObjectFactory.java).

We should move this behavior outside the constructor, and probably add it to the factories that create these objects after they are fully initialized.

Another approach might be to provide a builder for each of these objects, and call this behavior in in the buildes, and have the factories call the builders instead of the constructors.

In any case, the constructors should not be part of the public API, as we are providing already a clear entry point for creating objects.