Rollbase Original ID Redesign—Improved Portability

With the new Globally Unique ID in Rollbase, you can securely create unique IDs for your metadata and data, making your applications easier than ever to share.

In this blog, we will look at changes made to the Original ID in the Progress Rollbase platform that we unveiled as part of version 4.2, and is also part of the latest version 4.3. This change vastly improved the robustness of application sharing and 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 APIs due to this change. We did 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 the 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 have moved away from the 64-bit auto-incrementing integer based Original ID. We now use a 128 bit based random GUID. A GUID is a Globally Unique Identifier. Widely known as a Universal Unique Identifier, a 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 ever being the same.

As Wikipedia puts it: “The probability of one duplicate would be about 50% if every person on earth as of 2014 owned 600 million GUIDs.”

How Will This Affect Existing Installations?

Since Rollbase v4.2, all Original IDs for metadata and data have been GUIDs. These are stored as a Base64 encoded String.

This change has an effect on the following areas:

Database Schema

All the table definitions with an Original ID as an 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. There is 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:

The OpenEdge database doesn’t support modifying the data-type of an existing column by using an 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 a 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 APIs are affected and fixing them would be very easy. The APIs in discussion here are REST, SOAP, Client-side and Server-side. If you have written a client to call out Rollbase APIs 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 api.wsdl and metadata.xsd to ensure things work seamlessly in 4.2 and beyond.

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

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 and after.

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 IDs are now Strings, ex:

Affected APIs

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

Redesigned for Improved Portability

The key effect of the new GUID is to improve the application sharing and portability of your applications. These changes are necessary for us to ensure that you have the perfect platform to develop and share your applications, which is always our goal. This is a first step towards many more exciting features we plan to add to the platform further down the road.