[docs] add dynamodb schema document #9

harunalfat · 2022-03-02T08:10:57Z

Summary:

Add document for dynamoDB schema

riandyrn · 2022-03-02T09:16:26Z

docs/dynamodb.md

+- `can_be_partner`, Boolean => flag for a pokemon that be able to be choose as a partner
+- `can_be_enemy`, Boolean => flag for a pokemon that be able to become an enemy


I think these fields should be replaced with following field:

type, String => the pokemon type, valid values: PARTNER, ENEMY

Then we could use this field as partition key in global secondary index (GSI).

So when we want to query for available Pokemon partners, we could query this GSI with type=PARTNER or type=ENEMY if we want to query enemies.

If we are still using can_be_partner & can_be_enemy fields, we need to scan the whole table first then apply the filter. We should avoid scan operation in DynamoDB since it is usually very expensive.

can we make a Pokemon support both of the types?

e.g. Pikachu can be either partner or enemy. Or this is a case that we do not need to support currently?

Maybe we can put the roles (PARTNER, ENEMY) in a set and make it indexable? I'm totally newbie with DynamoDB here.. 😅

Yes we can. You can make the type field optional. So in Pikachu we could set type=PARTNER.

When we want to query partner, we could use the type index. If we want to query enemy we could use scan table operation.

Maybe we can put the roles (PARTNER, ENEMY) in a set and make it indexable?

No, in DynamoDB this is not possible. Index in DynamoDB only support scalar types.

I'm totally newbie with DynamoDB here.. 😅

No problem, this common pitfall for someone who just use DynamoDB. 😃

aaah, understood, that's how the index query works. Okay, lemme update necessary things

docs/dynamodb.md

isdzulqor · 2022-03-02T09:23:31Z

docs/dynamodb.md

+- `partner.health`, Number => remaining health of player's partner
+- `enemy.id`, String => identifier of opposite partner
+- `enemy.health`, Number => remaining health of opposite partner
+- `last_damage.partner`, Number => last inflicted damage to player's partner
+- `last_damage.enemy`, Number => last inflicted damage to opposite partner


Missing the definition of last_damage, partner, and enemy field. It should be Map type

got it 👌

isdzulqor · 2022-03-02T09:23:52Z

docs/dynamodb.md

+- `battle_stats.max_health`, Number => maximum health (on battle start) of a pokemon
+- `battle_stats.attack`, Number => number of damage that can be inflicted by a pokemon
+- `battle_stats.defense`, Number => number of damage reducer for a pokemon (damage = enemy.attack - your_partner.defense)
+- `battle_stats.speed`, Number => chance for getting a turn in battle, higher means more likely to get a turn in battle RNG


Missing the definition of battle_stats field. It should be Map type

…elds;

riandyrn · 2022-03-03T05:21:30Z

docs/dynamodb.md

 - `battle_stats.max_health`, Number => maximum health (on battle start) of a pokemon
 - `battle_stats.attack`, Number => number of damage that can be inflicted by a pokemon
 - `battle_stats.defense`, Number => number of damage reducer for a pokemon (damage = enemy.attack - your_partner.defense)
 - `battle_stats.speed`, Number => chance for getting a turn in battle, higher means more likely to get a turn in battle RNG


I think it's better if you add 1 indentation here. This is to make it clear max_health, attack, defense, & speed is under battle_stats. In think it is okay too if you remove the battle_stats prefix.

Here is what I mean:

battle_stats, Map => holds battle stats related information of a pokemon

max_health, Number => maximum health (on battle start) of a pokemon

attack, Number => number of damage that can be inflicted by a pokemon

defense, Number => number of damage reducer for a pokemon (damage = enemy.attack - your_partner.defense)

speed, Number => chance for getting a turn in battle, higher means more likely to get a turn in battle RNG

riandyrn · 2022-03-03T05:25:01Z

docs/dynamodb.md

 - `battle_stats.max_health`, Number => maximum health (on battle start) of a pokemon
 - `battle_stats.attack`, Number => number of damage that can be inflicted by a pokemon
 - `battle_stats.defense`, Number => number of damage reducer for a pokemon (damage = enemy.attack - your_partner.defense)
 - `battle_stats.speed`, Number => chance for getting a turn in battle, higher means more likely to get a turn in battle RNG
 - `avatar_url`, String => url for avatar image of a pokemon
- `can_be_partner`, Boolean => flag for a pokemon that be able to be choose as a partner
- `can_be_enemy`, Boolean => flag for a pokemon that be able to become an enemy
+- `type`, String => the pokemon type, valid values: `PARTNER`, `ENEMY`


So you don't want to make it possible for Pikachu to also become possible enemy?

If do you want to do so, write the spec like this:

type, String, OPTIONAL => the pokemon type, valid values: PARTNER

You can also change the name type into extra_role (since this is optional), so the spec would be:

extra_role, String, OPTIONAL => the pokemon type, valid values: PARTNER

okay, I think extra_role is more fit than type, also to avoid using reserved words. Noted 👌

riandyrn · 2022-03-03T05:27:54Z

docs/dynamodb.md

 },
 ```

 **Relevant Indexes:**
 - `PRIMARY_KEY` => `id`
+- `GLOBAL_SECONDARY_INDEX` => `type`


It should be:

type => type

This is the style we usually use to define GSI. Or you could also make it like this:

type, GSI => type

This is to make it clear that this index is GSI not LSI.

riandyrn · 2022-03-03T05:33:50Z

docs/dynamodb.md

+- `partner`, Map => holds information of player's pokemon
 - `partner.health`, Number => remaining health of player's partner
+- `enemy`, Map => holds information of enemy's pokemon
 - `enemy.id`, String => identifier of opposite partner
 - `enemy.health`, Number => remaining health of opposite partner


Make it like this:

partner, Map => holds information of player's pokemon

health, Number => remaining health of player's partner

enemy, Map => holds information of enemy's pokemon

id, String => identifier of opposite partner

health, Number => remaining health of opposite partner

riandyrn · 2022-03-03T05:44:21Z

Btw, in Battles table, why don't you put all the data there, @harunalfat?

Like for example the complete data for partner & enemy.

By doing this when you are fetching the battle data you could only fetch it one time. No need to lookup from Pokemon Table.

This is also the same case with partner data in Games.

I think by putting all the data in the object creation it will make the query more efficient. Notice that DynamoDB is key value store similar to Redis. So you cannot have join queries.

harunalfat · 2022-03-03T07:00:11Z

Btw, in Battles table, why don't you put all the data there, @harunalfat?

Like for example the complete data for partner & enemy.

By doing this when you are fetching the battle data you could only fetch it one time. No need to lookup from Pokemon Table.

This is also the same case with partner data in Games.

My main concern is data consistency, if a Pokemon get an update in its battle stats, should it be reflected in running games or not? This is a very common concern with NoSQL. If running battles won't reflect Pokemon stats update, I agree filling all necessary data altogether is a much better way

…intion;

riandyrn · 2022-03-03T07:16:15Z

My main concern is data consistency, if a Pokemon get an update in its battle stats, should it be reflected in running games or not?

Hmm.., ok, let say we do some adjustment to Pokemon data.

This will affect:

partner & enemy data on running battle
partner data on running game

From the context of running battle, I think it's better if we keep the battle data as before the adjustment. By doing this we could keep the consistency for that running battle.

For the running game perspective I agree with you.

harunalfat · 2022-03-03T07:40:21Z

Hmm.., ok, let say we do some adjustment to Pokemon data.

This will affect:

partner & enemy data on running battle

partner data on running game

From the context of running battle, I think it's better if we keep the battle data as before the adjustment. By doing this we could keep the consistency for that running battle.

Ok, seems good. So, I'll persist states of both partner and enemy into Battle entity. It'll becomes

{
    "game_id": "1a34a63d-afe6-4186-8628-13a25eaa6076",
    "state": "DECIDE_TURN",
    "partner": {
          "id": "b1c87c5c-2ac3-471d-9880-4812552ee15d",
          "name": "Pikachu",
          "battle_stats": {
              "max_health": 100,
              "attack": 25,
              "defense": 5,
              "speed": 15,
              "health": 75
          },
          "avatar_url": "https://assets.pokemon.com/assets/cms2/img/pokedex/full/025.png",
          "extra_role": "PARTNER"
      },
    "enemy":{
        "id": "88a98dee-ce84-4afb-b5a8-7cc07535f73f",
        "name": "Squirtle",
        "battle_stats": {
            "max_health": 100,
            "attack": 20,
            "defense": 10,
            "speed": 15,
            "health": 60
        },
        "avatar_url": "https://assets.pokemon.com/assets/cms2/img/pokedex/full/007.png"
      },
    "last_damage": {
        "partner": 10,
        "enemy": 25
    }
}

and when running a new battle, all pokemons data will be re-pulled again from Pokemons table. Is this good enough?

And seems like partner data in game entity only acts as an argument for new battle's partner, which will be re-pulled. So, I don't think partner field in Games need to be filled with complete data. WDYT?

riandyrn · 2022-03-03T07:48:14Z

when running a new battle, all pokemons data will be re-pulled again from Pokemons table. Is this good enough?

Yup👍🏻

So, I don't think partner field in Games need to be filled with complete data. WDYT?

Yup, you are right.

riandyrn

Great work, @harunalfat! 🎉🎉🎉

You may now build the adapter. 👍🏻

[docs] add dynamodb schema document

c8d4c48

harunalfat self-assigned this Mar 2, 2022

harunalfat requested review from isdzulqor, knightazura and riandyrn March 2, 2022 08:11

riandyrn requested changes Mar 2, 2022

View reviewed changes

isdzulqor requested changes Mar 2, 2022

View reviewed changes

[docs] fix Pokemons table type group; add additional info for some fi…

1a49459

…elds;

isdzulqor approved these changes Mar 3, 2022

View reviewed changes

knightazura approved these changes Mar 3, 2022

View reviewed changes

harunalfat requested a review from riandyrn March 3, 2022 04:15

riandyrn requested changes Mar 3, 2022

View reviewed changes

[docs] fixing dynamodb schema; apply indentation to nested object def…

741310b

…intion;

[docs] include partner and enemy complete data within game object

2d380be

harunalfat requested a review from riandyrn March 3, 2022 09:16

riandyrn approved these changes Mar 3, 2022

View reviewed changes

riandyrn merged commit 478c380 into master Mar 3, 2022

riandyrn deleted the docs/dynamodb-document branch March 3, 2022 09:32

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[docs] add dynamodb schema document #9

[docs] add dynamodb schema document #9

harunalfat commented Mar 2, 2022

riandyrn Mar 2, 2022

harunalfat Mar 2, 2022

riandyrn Mar 2, 2022

harunalfat Mar 2, 2022

isdzulqor Mar 2, 2022

harunalfat Mar 2, 2022

isdzulqor Mar 2, 2022

harunalfat Mar 2, 2022

riandyrn Mar 3, 2022

riandyrn Mar 3, 2022

harunalfat Mar 3, 2022

riandyrn Mar 3, 2022

harunalfat Mar 3, 2022

riandyrn Mar 3, 2022

riandyrn commented Mar 3, 2022 •

edited

Loading

harunalfat commented Mar 3, 2022 •

edited

Loading

riandyrn commented Mar 3, 2022

harunalfat commented Mar 3, 2022 •

edited

Loading

riandyrn commented Mar 3, 2022

riandyrn left a comment

		- `can_be_partner`, Boolean => flag for a pokemon that be able to be choose as a partner
		- `can_be_enemy`, Boolean => flag for a pokemon that be able to become an enemy

[docs] add dynamodb schema document #9

[docs] add dynamodb schema document #9

Conversation

harunalfat commented Mar 2, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

riandyrn commented Mar 3, 2022 • edited Loading

harunalfat commented Mar 3, 2022 • edited Loading

riandyrn commented Mar 3, 2022

harunalfat commented Mar 3, 2022 • edited Loading

riandyrn commented Mar 3, 2022

riandyrn left a comment

Choose a reason for hiding this comment

riandyrn commented Mar 3, 2022 •

edited

Loading

harunalfat commented Mar 3, 2022 •

edited

Loading

harunalfat commented Mar 3, 2022 •

edited

Loading