Global Moderators group

Paul Winterhalder

Agreed @armitage - the bulk messaging feature is planned for the use case you describe... (and yup - still coming ).

Paul Winterhalder

Hi - you custom entity based solution for this is sound.

You also might want to check on the messaging system - which has an "inbox" and a concept of whether entries have been "read" or not. It might do what you are looking for more directly?

Paul Winterhalder

Note - the client devs have asked me to point out that this serialization challenge is only for folks using LitJson. All the other libs seem to handle things just fine.

Paul Winterhalder

Hi @LEE-JONG-GUN - did you have any luck with that?

Paul Winterhalder

Hi Lee,

We are having difficulties recreating the issue.

Can you post an example JSON response where you are seeing the issue... it may help us to track down what it causing it...

Thanks,

Paul.

Paul Winterhalder

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.

Paul Winterhalder

What sort of edits are you doing to the leaderboards that updating multiple of them at the same time would be appropriate / convenient?

Paul Winterhalder

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

HI @moondory77 - you mean an option to not even include the custom entity collection definitions? What is your use case for that?

Paul Winterhalder

Okay - to start - you really should be updating to Production ONLY from Staging.

That said, your challenge is due to the fact that your app is dynamically creating new Division Sets based on the results of previous tournament rounds.

Do not overwrite Leaderboard, Tournaments, etc. configurations" would allow you to deploy without updating any of Leaderboards, Tournaments and Division Sets.

That said - if you DID want to update static Leaderboards and Tournaments - but NOT the dynamically generated Division Sets - then we don't currently have an option that separates those.

We can look into adding a new option that accommodates this:

Do NOT overwrite Leaderboard, Tournaments, Division Sets configurations

Do NOT migrate Division Set configs <- if above is unchecked, then this one is selectable. If above is checked, then this one is unselectable but checked by default.

Would this new option give you what you are looking for?

Paul.

Global Moderators

Posts

Member List