Request for Granular Migration Options in Deployment (Excluding DivisionSetIds)
-
HI @moondory77 - you mean an option to not even include the custom entity collection definitions? What is your use case for that?
-
Ah - I think I see what you are doing.
Instead of constantly creating and deleting collections - why not just create the tournament config records (objects) - and then delete them. If just take the nameing convention you are using (i.e. "WEEKLY_DIVISION_CONFIG_007_DEVELOPMENT") - and made that part of the of the record instead - you wouldn't have to keep creating and deleting whole collections.
And you can just set a TTL for the records themselves - so that they clean themselves up after 10 days or so.
Paul.
-
@Paul-Winterhalder Thank you for your response.
To provide more context on our current architecture, we utilize CustomEntities by assigning one collection per tournament (e.g., WEEKLY_DIVISION_CONFIG_007_DEVELOPMENT for the Week 7 tournament). Each of these collections then contains multiple records, which store the meta-information for the division groups within that specific tournament.
We adopted this structure to dynamically create and manage the required number of division groups for each weekly tournament with minimal overhead.
If we were to manage these as individual records within a single collection as you suggested, we would need to implement additional indices to distinguish groups by week and perform extra queries for every update. We specifically chose to manage them as separate collections to simplify this logic and avoid unnecessary complexity.
Given this workflow, moving to a record-based management system would significantly increase our implementation's complexity.
With that in mind, would it be feasible to add an option in the Deployment settings to include or exclude specific CustomEntity collections from the migration? This feature would greatly help us maintain our current efficient workflow while safely deploying other configurations.
-
Hmm - deployment is a very complex process - and in this case the complexity of picking and choosing what collection definitions get migrated over outweighs the complexity you would have to add a new field "week" to your collections and queries.
So apologies - but you should make the appropriate changes so that you have a "week" field in your collections (with appropriate indexes).
In compensation - I can offer up that:
- We ARE adding the ability to exclude Division Set Configs from deploys (as you requested) <-- this should be available next week sometime.
- And we DO now support migrating META data WITHOUT SCRIPTS via the builder API... (that got patched YESTERDAY!)
I hope you can understand.
-
Thank you!
-
hi. @Paul-Winterhalder
Is there an update regarding the option to exclude only the division set when deploying leaderboards?
(This is also needed for the builder API)
waiting for news about this update. -
Hi @noah - just checked and it's still in test. I'm checking with the team.
-
@noah - the servers have been patched. You now have the option to exclude division set configs during deploy.
-
hi. @Paul-Winterhalder
https://builder.docs.braincloudservers.com/#a4b146d3-03a2-497a-a0a1-b85ef005123d
I have verified that it works on the Portal Console web.
Could you please update the builder API payload?
It needs to be added to the deployment automation API.
Thank you. -
Hi @noah ,
This support has already been added to the Builder API. The new options can be specified when importing app configuration data OR when deploying an app.
When importing app configuration data, there is a new optional 'preserveDivisionSetConfigsOverride' parameter that can be specified. If not specified, it will default to whatever the value is for 'preserveLeaderboardTournamentConfigs'.
When deploying from one app to another, there is a new optional 'divisionSetConfigOverrides' parameter that can be specified in the 'options.meta.excludes' section. If not specified, it will default to whatever the value is for 'leaderboardsTournaments'.
I will endeavour to get our Builder API docs updated with these new parameters. Let us know if you encounter any issues using them.
Thanks!
Greg
