Hi,
Is it possible to do CRUD operations on index table. in case anyone one tiried please guide me on the same.
Hi Suchita,
While I haven’t tried this myself, I wouldn’t recommend performing direct CRUD operations on an Index table. Since Index tables act as copies of data extracted from the BLOB (usually via Declare Index rules), updating them directly isn’t a best practice.
If you manually modify the data in the Index table, it creates a data discrepancy with the source record. Furthermore, the next time the source record is updated and saved, your manual changes to the Index table will be completely overwritten by the fresh data from the BLOB.
It’s best to perform any updates directly on the primary source data and let the system automatically handle updating the index.
Index tables are not meant to be treated like normal business tables for manual CRUD operations. Index tables are usually maintained by Declare Index processing, so the recommended pattern is to create, update or delete the source record and let Pega populate or clean up the index entries automatically. The index data is derived data and manual inserts/updates/deletes can become inconsistent with the source object if Pega later regenerates or recalculates the index rows
@suchitad Can you share the requirement and what you want to achieve so we better understand on the use case here rather than directly updating the Index table records instead of source records.
In our project, we support bulk uploads of 500 to 1,000 records. Storing all of this data on the pyWorkPage could lead to performance issues. To address this, we plan to temporarily store the uploaded data on the WorkPage. When the user navigates to the next screen, the WorkPage data will be removed using Page-Remove. Meanwhile, the uploaded data will already be stored in the Index table.
For the CRUD operations, we will populate the data from the Index table . This approach helps improve performance and avoids the need to create a new Data Table.
Your concern about not keeping 500–1,000 uploaded rows on the pyWorkPage is valid, and Pega explicitly recommends keeping clipboards small and removing pages when they are no longer needed. But using an index table as a temporary working store for user-maintained CRUD is still not a great fit, because index tables are meant as derived/search structures, not as a primary transient data store.
The risky part is using the index table as the operational store for later CRUD. Even though pr_index tables are lightweight and optimized for reporting/search scenarios, they are still intended as index/derived storage rather than a business-maintained working table. Once users start editing rows directly from there, the table is no longer acting like an index. It is acting like a normal business table, and that is where the design becomes fragile
A better approach would be to use a dedicated data object/table for the uploaded rows, load only the needed subset into the clipboard when the user works on a page and clean up old staging rows afterward.
If the data is user-editable, it deserves a proper data object or staging table. If the data is only derived for lookup/reporting, then an index table is fine.
So for your use case, I would recommend creating a separate Data Object with one of the keys as your work ID and refer to the new Data object with your loaded 500/1000 records from your work object to keep the design clean and scalable
I agree with @RaviChandra , @VVNagaSaiN comments.
The main concern is that Index tables are derived data maintained by Pega’s Declare Index mechanism. If Pega regenerates or updates the index entries, any user-maintained changes could become inconsistent or be overwritten.
For your use case of handling 500–1,000 uploaded records and reducing clipboard footprint, I would recommend using a dedicated staging Data Object (or temporary work table) keyed by the Work ID rather than an Index table.
I am curious on this as well. I recently had a similar ask, if the import is going to take so long, why not use a wait shape or staging assignment and do the processing offline? Put a message like “processing request, please return in a few minutes”?
I have seen this done even before Constellation. If processing was going to take a while, or involve orchestrating external systems, then parking the user on another shape or even the confirmation screen might be better than trying to doing something with index tables or other data objects?
Store the bulk-uploaded records in a separate, dedicated data table instead of the Index table, using the work item’s ID as one of its keys. When a user opens a record to work on, load only that specific set of rows from this table rather than keeping all the data on the page. Once the task is finished, clear out the old staged rows. This keeps the Index table free for its proper role of search and reporting, while giving the application a clean, scalable way to perform CRUD operations on large bulk uploads.