Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The database used is H2 . The information is stored in a copy of the database_schemeschema.sql file for PostgreSQL with the following modifications:

  • removal of the function that provides the next value of a sequence
  • removal of clausule "WITH TIME ZONE" from TIMESTAMP values
  • removal of DEFAULT NEXTVAL('<seq>') constructs due to incompatibility. DatabaseManager has been changed to add the proper ID to the column. Proposed to change the affected valued to IDENTITY values, that include autoincrement.
  • removal of UNIQUE constructs due to incompatibility. Tests will need to verify uniqueness
  • replaced BIGSERIAL by BIGINT
  • replacing getnextid for NEXTVAL on an INSERT for epersongroup
  • due to the parsing process some spaces have been added at the start of some lines to avoid syntax errors

Due to H2 requiring the column names in capital letters the database is defined as an Oracle database for DSpace (db.name) and the Oarcle compatibility mode for H2 has been enabled.

The code in the mock DatabaseManager has been changed so the queries are compatible with H2. The changes are minimal as H2 is mostly compatible with PostgreSQL . Redundant checks (like checking fi the database is Oracle) have been removed from the mockand Oracle.

As a note, the usage of a DDL language via DDLUtils has been tested and discarded due to multiple issues. The codebase of DDL Utils is ancient, and not compatible with H2. This required us to use HSQLDB, which in turn required us to change some tables definitions due to syntax incompatibilities. Also, we discovered DDL Utils wasn't generating a correct DDL file, not providing relevant metainformation like which column of a table was a primary key or the existing sequences. Due to the reliance of DatabaseManager on this metainformation, some methods were broken, giving wrong values. It seems that more recent code is available from the project SVN, but this code can't be recovered from Maven repositories, which would make much more cumbersome the usage of unit testing in DSpace as the developer would be required to download the code, compile it and store it in the local repository before being able to do a test. A lot of effort has been put to use the DDL, but in the end we feel using the database_schema.sql file is better.

...