Rollbase Original ID redesign – Improved portability

In this blog, we will look at changes made to Original ID in the Progress Rollbase platform as part of version 4.2. This change vastly improved the robustness of Application sharing & portability. We will also cover the impact on existing installations and how to fix them. At the end, we will look at the list of affected API’s due to this change. We did a thorough research in various aspects of the platform before attempting this change.

What is changing?

Rollbase is a low-code Rapid Application platform that helps create applications at an unprecedented speed and efficiency.

Rollbase currently uses auto increment 8-byte (64 bit) integers as Original ID for the metadata and data. The concept of Original ID is to act as a criterion to identify metadata and data. This becomes very important when apps are frequently being moved across Rollbase tenants or instances as it leads to ID conflicts. This is because the Original IDs are not unique across deployments.

As of Rollbase v4.2, we are moving away from the 64-bit auto-incrementing integer based Original ID. We will now be using a 128 bit based random GUID. A GUID is a Globally Unique Identifier. Widely known as Universal Unique Identifier, GUID enables us to uniquely identify any given resource across various Rollbase deployments. The 128-bit space is large enough to bring down the probability of two randomly generated GUIDs being same.

Wikipidea quotes – “the probability of one duplicate would be about 50% if every person on earth as of 2014 owned 600 million GUIDs“.

How this will affect existing installations?

Rollbase v4.2 onwards, all Original IDs for metadata and data will be GUIDs. These will be stored as Base64 encoded String.

This change has an effect on the following areas:

Database Schema

All the table definitions with Original ID as integer type have been changed to CHAR (22) in the create_xx.sql. An update script is provided for migrating from an older Rollbase version to v4.2. There are NO impact on indexes due to this change.

Special instructions:
1. Please take a backup of the database before running the update script during upgrade.
2. Please store the result/log of the update script execution for future reference.

Note for OpenEdge customers:
3. OpenEdge database doesn’t support modifying the data-type of an existing column by using SQL ALTER statement with a MODIFY. So, the chosen method implemented in the update script is:
– Create a temporary column.
– Copy the data from the existing Original ID column to the temporary column using the CAST function.
– Drop the existing Original ID column.
– Rename the temporary column as Original ID.
This means slightly longer downtime for database update.

API

There will be impact on the API users as they will have to make changes (if necessary) to NOT assume that the Original ID would be an integer value. Only a handful of these API’s are affected and fixing them would be very easy. The API’s in discussion here are REST, SOAP, Client-side & Server-side. If you have written a client to call out Rollbase API’s that assumes Original ID would be an integer while making or while processing the response of an API call, then you will need to fix them to use String. So, for example, all SOAP clients will have to be recompiled using the new v4.2 api.wsdl and metadata.xsd to ensure things work seamlessly in 4.2.

Please refer to the “Affected API’s” section for the list of affected REST, SOAP, Client-side & Server-side API’s. You don’t have to make any changes if you are not using any of these API’s.

Custom Code

As part of this, we are looking at any custom javascript/triggers etc. in your application that assumes that the Original ID is an integer. These references will have to be updated to use the Original ID as a String in v4.2.

Effect on Existing data?

There is absolutely NO effect on any existing application as the platform can work with existing integer Original IDs. These changes will have no effect on existing metadata and data. Your apps will continue to run as they were without any impact.

For cases of ‘Custom Code’ that use Original ID, please refer to the explanation offered in the previous section.

Original ID before 4.2 was an integer value, ex:

Original ID integer

Original ID’s are now Strings, ex:

Original ID GUID

Affected API’s

For the complete list of Affected API’s, please refer to Migrating original ID generation to GUID.

Conclusion

By now you would have understood the complexity of the attempted changes. These changes are necessary to ensure  that we have the perfect platform for the users to develop and share their applications. This is a first step towards many more exciting features we plan to add to the platform further down the road.