[solomax]

No description provided.

[solomax]

I haven't tested this one (was hoping github will do it for me ....)
@rzo1 how did you test it previously? run one-by-one with docker compose?

[rzo1]

I run it in docker, yes. Took ages

[solomax]

@rzo1 here are testing results

HSQL - GREEN!

Testing this one with mssql:2017-latest and got:

| [ERROR] org.apache.openjpa.persistence.jpql.functions.TestEJBQLFunction.testSubstringBeyondString -- Time elapsed: 0.147 s <<< ERROR!
| <openjpa-4.2.0-SNAPSHOT-r9910de6M fatal general error> org.apache.openjpa.persistence.PersistenceException: Invalid length parameter passed to the LEFT or SUBSTRING function.
| FailedObject: SELECT SUBSTRING(u.name, 10) FROM CompUser AS u WHERE u.name = 'Seetha' [java.lang.String]
| 	at org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:5938)
| 	at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:5898)
| 	at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:134)
| 	at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:115)

Oracle tests for whatever reason gave me:

| [INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.265 s -- in org.apache.openjpa.persistence.jdbc.query.TestNativeQueryParameterBinding
| [INFO] Running org.apache.openjpa.persistence.jdbc.query.TestQueryParameterBinding
| [ERROR] Tests run: 23, Failures: 0, Errors: 6, Skipped: 0, Time elapsed: 4.721 s <<< FAILURE! -- in org.apache.openjpa.persistence.jdbc.query.TestQueryParameterBinding
| [ERROR] org.apache.openjpa.persistence.jdbc.query.TestQueryParameterBinding.testRepeatedNamedParameters -- Time elapsed: 0.153 s <<< ERROR!
| <openjpa-4.2.0-SNAPSHOT-r9910de6M nonfatal general error> org.apache.openjpa.persistence.PersistenceException: ORA-12516: Cannot connect to database. Listener at host localhost port 1521 does not have a protocol handler for TCP ready or registered for service openjpatst. (CONNECTION_ID=oxmAHkT4R4qMIRU8V/i+HA==)
| https://docs.oracle.com/error-help/db/ora-12516/
| 	at org.apache.openjpa.jdbc.meta.MappingTool.record(MappingTool.java:687)

while docker ps results:

09966c49f755   catthehacker/ubuntu:act-latest               "tail -f /dev/null"      16 minutes ago      Up 16 minutes                                                           act-Databases-build-Java-21-test-oracle-docker-23-slim-48b9c76a501d82ee71039480798c00fee25138dfe751ff65af51cecc0f95c4ad
2518d030af23   gvenzl/oracle-free:23-slim                   "container-entrypoin…"   16 minutes ago      Up 16 minutes (healthy)   0.0.0.0:1521->1521/tcp, [::]:1521->1521/tcp   act-Databases-build-Java-21-test-oracle-docker-23-slim-48b9c76a-09efbcfd76289cf3581de8b423b7dd2da46699ffe49681dd4a506fbe6f9e65c8

and telnet localhost 1521 is able to connect

The only difference for oracle what I can see is absent init.sql from src/test/sql/oracle-docker/01-processes.sh
Not sure how to connect it in yaml .....

BTW why did you switch to gvenzl/oracle-free from gvenzl/oracle-xe. This new Oracle has only 1 version and requires some init script ....

[rzo1]

@solomax ORA-12516 is the process limit: the test suite opens more connections than the image allows by default (processes=200). That is not specific to oracle-free; the old init.sql for XE never actually ran. That's why #281 added src/test/sql/oracle-docker/01-processes.sh (processes=1000, sessions=1600, restart), which the profile mounts into /container-entrypoint-initdb.d.

A GitHub services: container starts before the checkout, so it can't mount the script. Two options:

1. Keep the service and run the script after the checkout:

      - name: 'Raise Oracle processes and sessions'
        run: docker exec -i ${{ job.services.oracle.id }} bash < src/test/sql/oracle-docker/01-processes.sh

2. Drop the service and let the profile start the container, as locally:

      - run: mvn -N -B -Ptest-oracle-docker docker:start
      - run: mvn -Ptest-oracle-docker -B clean install --file pom.xml
      - if: always()
        run: mvn -N -B -Ptest-oracle-docker docker:stop

Why oracle-free instead of oracle-xe: I'm working on an Apple Silicon MacBook, and gvenzl/oracle-xe is amd64 only, while oracle-free also runs natively on arm64. Also, Oracle has replaced XE with Database Free (23). The TCK and unit test runs for the Oracle PRs were done on Free 23. 23-slim follows the latest 23 release; we can pin a concrete tag if we want reproducible CI. XE should work too with the same init script, since gvenzl/oracle-xe runs /container-entrypoint-initdb.d as well.

[rzo1]

@solomax the SQL Server failure of testSubstringBeyondString is fixed in #284.

[solomax]

Thanks for the help @rzo1 :)
I'll ask one more question before will make changes :)

Why are we manually specifying services will lots of copy/paste from pom.xml while we can use same configuration with docker:start/docker:stop ?
Maybe it worth to use it with all databases?

[rzo1]

@solomax Good point, I'd go for it. Services are mainly there because they were the quickest way to get a database up. With docker:start/docker:stop:

• The pom is the only place for image, env and ports, and CI runs exactly what we run locally.
• Things a service can't do work: the Oracle init script mount, and the MySQL --lower_case_table_names arg from the profile, which the CI service silently drops today.
• The matrix version can be passed in, e.g. -Dmysql.server.version=${{ matrix.version }}.

One thing is missing first: only the Oracle profile has a <wait>. For MySQL, MariaDB, PostgreSQL and SQL Server, docker:start returns before the database accepts connections. A service waits for its health check, which is why it works there. Each profile needs a <wait> on the "ready" log line, as the Oracle one has. That's also better locally.

I'd keep #283 to what it does now and use docker:start only for Oracle there, since it needs the init script. Moving the other databases over can be a small follow-up PR.