Skip to content

[#582] [#770] Fixes and enhancements to the test-force-upgrade pipeline job

Narayanan Iyerrequested to merge
nars1/YDBOcto:test-force-upgrade into master

Background

  • While working on the PRIMARY KEY constraint (#770 (closed)) task, I noticed an issue in the code and realized the same issue should have existed with UNIQUE constraints (#582 (closed)) too as they share the same code.

  • An example issue with UNIQUE constraints is illustrated below.

    I first create a table in Octo with a UNIQUE constraint.

    OCTO> create table tmp (id integer unique);

    I then examine the text table definition that the above command created. It can be examined in the following global at the YDB> prompt.

    YDB>write ^%ydboctoschema("TMP","text",0)
CREATE TABLE `TMP` (`ID` INTEGER CONSTRAINT TMP_ID_KEY UNIQUE (ID) DELIM "") GLOBAL "^%ydboctoDK8x9V2YiyPMRxcDYOMpB0K(keys(""%YO_KEYCOL""))" DELIM "|" READWRITE;

    The purpose of this text definition is to be able to recreate the table in case an auto-upgrade is needed (e.g. if a newer version of Octo that has an incompatible binary table definition format is installed).

    Therefore, the above command should be able to recreate the exact same table.

    But it turns out to have a syntax error as can be seen below.

    OCTO> CREATE TABLE `TMP` (`ID` INTEGER CONSTRAINT TMP_ID_KEY UNIQUE (ID) DELIM "") GLOBAL "^%ydboctoDK8x9V2YiyPMRxcDYOMpB0K(keys(""%YO_KEYCOL""))" DELIM "|" READWRITE;
LINE 1: ...R CONSTRAINT TMP_ID_KEY UNIQUE (ID) DELIM "") GLOBAL "^%ydbocto...
                                          ^
syntax error, unexpected LEFT_PAREN, expecting CHECK or NOT or PRIMARY or UNIQUE

  • I then started wondering why the above issue did not get caught in the test-force-upgrade pipeline job as the UNIQUE constraint changes are already merged and the purpose of that job is to examine all CREATE TABLE queries in the Octo test system (under tests/fixtures/*.sql) and execute them and find out if they have any such issues when run through a forced upgrade.

  • That is when I realized there are 2 issues.

Issue 1

  • The tools/ci/build.sh script (which implements the test-force-upgrade pipeline job) only searches for queries that contain CREATE TABLE (upper case). There are lots of queries in tests/fixtures/*.sql which contain create table (lower case version).

Issue 2

  • There are queries that contain CREATE TABLE and define UNIQUE constraints but those did not get caught by the test-force-upgrade pipeline job.

  • An example is the following query (below contents are pasted from the artifacts of a test-force-upgrade pipeline job run using the master branch).

    $ cat create_table.sql
    .
    .
    946 -- Test that READWRITE is compatible with table-level DELIM and column-level PRIMARY KEY/KEY NUM/NOT NULL/UNIQUE
    947 CREATE TABLE MYTBL9 (id INTEGER PRIMARY KEY, id2 INTEGER KEY NUM 1, firstname VARCHAR(10) NOT NULL UNIQUE) DELIM "#" READWRITE;
    .
    .

$ cat newsrc/create_table-0343.sql
CREATE TABLE MYTBL9 (id INTEGER PRIMARY KEY, id2 INTEGER KEY NUM 1, firstname VARCHAR(10) NOT NULL UNIQUE) DELIM "#" READWRITE;

  • I was expecting this query to have encountered the syntax error. But turns out it had the following error instead.

    $ cat newsrc/create_table-0343.sql.2.out
[ERROR]: ERR_YOTTADB: YottaDB error: 150381114,(Call-In),%YDB-E-DLLCHSETM, Routine %ydboctoInit in library /builds/nars1/YDBOcto/build/##SRCDIR##/_ydbocto.so was compiled with CHSET=M which is different from $ZCHSET. Recompile with CHSET=UTF-8 and re-link.

  • And the same error happened with oldsrc (regular) as well as newsrc (force-upgrade) runs of Octo.

  • And the tools/ci/build.sh script only checked if the outputs of both runs were the same and because both runs contained the same error, it considered this as a pass and moved on which was incorrect as it masked the real issue hiding underneath.

  • The issue was an export ydb_routines line which included a _ydbocto.so. This was the non-UTF8 version whereas ydb_env_set (sourced by the tools/ci/build.sh script at the start) by default now switches to ydb_chset=UTF-8 (due to YottaDB/DB/YDB@282b5569) resulting in this error. And that mismatch is the cause of the %YDB-E-DLLCHSETM error.

Fix

  • For Issue 1, the fix is to enhance tools/ci/build.sh to search for create table type of queries too. But because we finally pass such queries to a python script (split_queries.py), we convert the lower case create table to an upper case CREATE TABLE before writing all such queries to create_table.sql. This will ensure a lot more CREATE TABLE queries from the Octo test system will now participate in the test-force-upgrade pipeline job and hence result in more test coverage.

  • For Issue 2, the fix is to remove the _ydbocto.so from the export ydb_routines line in tools/ci/build.sh. Additionally, a check for %YDB-E-DLLCHSETM has been explicitly added so we flag this as a real error if this is every encountered in the future (e.g. if ydb_env_set switches to ydb_chset=M as the default etc.). That way we avoid masking real issue (like the UNIQUE constraint issue above).

Merge request reports