Question
Handle Parallel Development for Data Tables
Hi,
We have multiple releases and there is a chance that data table attribute/structure might get changed release wise. Since development of these release may overlap each other, is there any way to handle a single data table to support parallel development without affecting the development work of previous release? We don't want to create new table release wise.
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
let me explain in this way- we have 2 app releases running on same pega instance. First release and second release might overlap so there is chance where content of tables in data type in release 1 might get changed in release 2.
Since we store lots of business rules in Data table so in case data table content for Release 2 is changed then the same change will also affect the developer who is working in release 1 as table in the data type is common for both the releases.
Is there any way where we can seggregate tables without creating another new table for release 2?
Accepted Solution
I don't think it is possible to achieve as data instances cannot be versioned.
One workaround is,
1.You need to include an additional column in data tables to store release number matching your application/access group version.
2. Wherever you are referencing these data instances, update the logic to fetch record which has maximum release number but less than or equal to your application or access group version number.
So, the user 1 with application version 01-01-01 will access the data instance with release number 1 and the user 2 with application version 01-01-02 will access the data instance with release number 2. [We can handle this logic in multiple ways based on your application]
3. You can optionally create an utility to delete the old version of data instances
Thanks for the advice Prakash but considering the complexity of our application, this approach will make things more complex. I guess we need to handle this on case-by-case basis. (we will make changes to those rules only which are referring to those data tables).
Thanks again for your valuable suggestion!
If you mean that two versions of your app on different Pega instances are going to be viewing the same external data records, then both will certainly need both to be prepared to understand the one data record configuration.