What is changing ?
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 criteria to identify metadata and data when they are moved across Rollbase tenants or instances. But the Originial IDs are not unique across Rollbase deployments which often leads to ID conflicts when moving from one Rollbase deployment to another.
As of Rollbase v4.2, we are moving away from the 64 bit auto-incrementing integer based Original ID to a 128 bit based random GUID. A GUID is a Globally Unique Identifier otherwise known as Universal Unique Identifier that enables us to uniquely identify any given resource across various Rollbase deployments. The 128 bit space is so large that it brings down the probability of two randomly generated GUIDs being same to negligible.
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 that will be stored as Base64 encoded String. This has an effect on the following areas:
Database Schema
All the database table definitions that had the Original ID as integer type have been changed to CHAR(22) in the create_xx.sql. There will be an update script made available for those who would be 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. We have identified and made sure that only a handful of these API's are affected and the 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 (attached) 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. There is no change involved 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 will be absolutely NO effect on any existing application that has been developed on earlier versions of Rollbase as the platform is designed to support the existing integer Original IDs. There won't be any change in metadata and data stored in the database and no representational changes on the UI after a v4.2 upgrade. 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: 9058 but with 4.2, the Original ID's are now Strings ex: PM_7voZ-QRaqCEmOMiU9Zg
Affected API's
REST
API's that accept Original ID as an input:
- getCount
- getPage
- runTrigger
- bulkUpdate
- bulkCreate
- bulkCreateOrUpdate
- getRoleById
- getPermissionsByRole
- setPermissionsByRole
- getApplicationDef
- deleteApplicationDef
- getPermissionsByUser
- setPermissionsByUser
API's that return Original ID in the response:
- getRoles
- getRoleById
- getApplicationDef
- getFieldDef
- getObjectDef
- getRelationshipDef
SOAP
API's that accept Original ID as an input:
- getCount
- getPage
- bulkCreate
- bulkCreateOrUpdate
- bulkUpdate
- getApplicationDef
- deleteApplicationDef
API's that return Original ID in the response:
- getApplicationDef
- getFieldDef
- getObjectDef
- getRelationshipDef
Client-side
API's that accept Original ID as an input:
- rbf_getCount
- rbf_getPage
- rbf_runTrigger
- rbf_getApplicationDef
- rbf_deleteApplicationDef
- rbf_getPage2
API's that return Original ID in the response:
- rbf_getApplicationDef
- rbf_getFieldDef
- rbf_getObjectDef
- rbf_getRelationshipDef
Server-side
API's that accept Original ID as an input:
- rbv_api.getCount
- rbv_api.runTrigger
- rbv_api.startApproval
- rbv_api.isAppInstalled
- rbv_api.runReport
- rbv_api.runTemplate
- rbv_api.getHostedAsText
- rbv_api.getHostedAsBinary
- rbv_api.getRoleById
API's that return Original ID in the response:
- rbv_api.getRoleById
[View:/cfs-file/__key/communityserver-discussions-components-files/25/api2.wsdl:320:240]
[View:/cfs-file/__key/communityserver-discussions-components-files/25/metadata.xsd:320:240]