ERP 2.50:QA test plan 2.50/UUID

Introduction

Currently in Openbravo ERP, database records are identified by one (in some tables it's two) numeric column which is known as primary key (PK). The value of a primary key cannot be repeated within the same table, or in other words once a primary key is taken it can't be used again in the same table while the record that identifies it is still in the table. Before any insertion in a database a PK is requested and reserved. This PKs are sequential numbers: for each request the reserved number is the next to the last reserved one for the table where it is going to be used. Additionally for each table two ranges of primary keys are maintained: one is for the system entries and another one for the common data entries. System entries are the ones that can be used by the system (they define application dictionary data and information shared among all the users).

As system information is intended to be shared between different installations the PKs for this kind of data is generated in a way that do not provoke collisions inter-installations, making thus possible to work different developers in different projects inserting data in the same tables at once. The way numbers are generated for these identifiers is having a different range for each development environment (it's called development environment ID).

Aim of the project

This project will affect all the tables in the application modifying their structure to be able to store UUIDs as primary key as well as all the queries to these tables.

Impact in the application

• UUIDs will be represented as varchar2(32) as an hexadecimal value without scores (-) for group separator. This will affect:
  • Change all the primary key column from number(10) to varchar2(32) to be able to store UUIDs.
  • The same applies for all the foreign key columns.
  • The same for non-db-FK columns that actually store references to other PKs (for example ad_tree_node.node_id, fact_acct.record_id, fact_acct.record_id2, etc...) and change its data type.
  • Create an UUID generator in Java and DB.
  • Adapt PL/SQL code to the new data types.
    • Types for PK and FK types must be transformed to varchar2(32).
  • Adapt WAD code to the new data types.
  • Adapt manual code to the new data types.
    • xsql file needn't explicitly cast char as they are doing with numbers so castings for these fields must be removed.

Test cases

• The environments will be:
  • Linux/Oracle-PostgreSQL
  • Windows/Oracle-PostgreSQL

• Test cases:
  • Acceptance test
  • Multiaccounting schema test plan
  • Project service management review
  • Create tables, columns, windows, tabs and fields. Steps for customizing

Results