Hi there
Is there a way to define Cube Summary Table indexes (non-unique) that can be delivered when patched/migrated to another environment? My understanding, at the moment, is one needs to do it in each environment - is this correct? If I am correct, is there any chance in the future of it being allowed to be defined in the Cube Summary Table Definition, so it can be migrated?
I did read @bethany.k ‘s post on the indexes on the unique indexes, but as mentioned above, this is specific to non-unique indexes we could deliver without having to add manually after migration(s).
Thank you.
Yes. As of 25.1, you can configure indexes on the summary data table record (table schema record with the name: summary table name + “Data”). The data table should be migrated/patched alongside the summary table when it is moved to different environments.
There is a caveat to this though - these index changes will only apply to summary tables activated ‘after’ the index change is made. It will not retroactively apply to existing active summary tables. Those would need to have the index configured manually in each environment on the corresponding activation data table record (summary table name + “Data” + random character string).
For a proper confirmation of expected behavior, once you have made your index changes and migrated/patched it to a different environment, if you activate the summary table there, you should see all of your expected indexes configured on the activation data table specific to that activation (summary table name + “Data” + random character string).
2 Likes
We decided on the tools side to not have indexes directly configured through the summary table definition to avoid having to duplicate the table schema index configuration subtables and maintain it in multiple apps.
OK, @jeremy.keller - thanks makes sense. I will look into this more and revert if I have more questions. Thanks so much for the feedback!