Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
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.
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.”
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:
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.
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:
This means slightly a longer downtime for database update.
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.
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:
For the complete list of Affected API’s, please refer to Migrating original ID generation to GUID.
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.
Manooj Murali is a Principal Software Engineer at Progress. He has been part of the Rollbase development team in Hyderabad for more than two years and has more than 8 years of experience overall in software development. He has led many feature developments like I18N, Marketplace, White-Labelling, JBOSS support, High Availability and more for Rollbase.
Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.