Human Resources Example - Table definition

[chemzo]

Hello!

I've been going through the documentation and it's not clear to me how the table definition in the first example ( https://electrodb.dev/en/examples/human-resources ) maps to the entities?

Is that just a base table definition that later needs to be manually updated?
Is there any tool to get a dynamodb table definition based on the Entities defined in a service?

Thank you!!

[zirkelc]

Hi @chemzo

ElectroDB is a library, similar to an ORM, that helps you to model your data in terms of entities (or objects) and query these entities efficiently. In contrast to classical SQL libraries, ElectroDB works with a single table (even if you could use multiple tables if you want to) and it uses some clever design around composite keys to distinguish different entities from each other.

Here is a typical table definition in CloudFormation JSON with pk as partition key and sk as sort key, and three global secondary indexes (GSI) named gsi1pk, gsi2pk, gsi3pk (partition key) and gsi1sk, gsi2sk, gsi3sk (sort key):

{
"EntityTable": {
      "Type": "AWS::DynamoDB::Table",
      "Properties": {
        "TableName": "nebula-api-dev",
        "BillingMode": "PAY_PER_REQUEST",
        "KeySchema": [
          {
            "AttributeName": "pk",
            "KeyType": "HASH"
          },
          {
            "AttributeName": "sk",
            "KeyType": "RANGE"
          }
        ],
        "AttributeDefinitions": [
          {
            "AttributeName": "pk",
            "AttributeType": "S"
          },
          {
            "AttributeName": "sk",
            "AttributeType": "S"
          },
          {
            "AttributeName": "gsi1pk",
            "AttributeType": "S"
          },
          {
            "AttributeName": "gsi1sk",
            "AttributeType": "S"
          },
          {
            "AttributeName": "gsi2pk",
            "AttributeType": "S"
          },
          {
            "AttributeName": "gsi2sk",
            "AttributeType": "S"
          },
          {
            "AttributeName": "gsi3pk",
            "AttributeType": "S"
          },
          {
            "AttributeName": "gsi3sk",
            "AttributeType": "S"
          }
        ],
        "GlobalSecondaryIndexes": [
          {
            "IndexName": "gsi1pk-gsi1sk-index",
            "KeySchema": [
              {
                "AttributeName": "gsi1pk",
                "KeyType": "HASH"
              },
              {
                "AttributeName": "gsi1sk",
                "KeyType": "RANGE"
              }
            ],
            "Projection": {
              "ProjectionType": "ALL"
            }
          },
          {
            "IndexName": "gsi2pk-gsi2sk-index",
            "KeySchema": [
              {
                "AttributeName": "gsi2pk",
                "KeyType": "HASH"
              },
              {
                "AttributeName": "gsi2sk",
                "KeyType": "RANGE"
              }
            ],
            "Projection": {
              "ProjectionType": "ALL"
            }
          },
          {
            "IndexName": "gsi3pk-gsi3sk-index",
            "KeySchema": [
              {
                "AttributeName": "gsi3pk",
                "KeyType": "HASH"
              },
              {
                "AttributeName": "gsi3sk",
                "KeyType": "RANGE"
              }
            ],
            "Projection": {
              "ProjectionType": "ALL"
            }
          }
        ]
      }
    },
}

When you compare it to the Human Resources example, you'll see that every index (the example has 5) maps to a partition and sort key.

[chemzo]

Thank you @zirkelc !

So the example Table definition in the Human Resources example doesn't relate at all to the entities (I see even the table name is different).
It would be great to align it to them or better remove it, as it only creates confusion in the current state.

Thank you and keep up the good work!

[zirkelc]

No, I think you misunderstood me. Entities don't map one-to-one to physical database tables, the HR example contains 3 which are all stored in a single table.

This is a common pattern when working with DDB: single-table-design where all your data is saved in a single "schema-less" table. The physical table has generic attributes like pk and sk and the entities define how these keys are generated.

Take a look at the ElectroDB playground and look out for the pk and sk values: Playground

Here is an example:

{
  "Key": {
        "pk": "$taskapp#team_green",
        "sk": "$tasks_1#project_core#task_45-6620"
    },
}

As you can see, these keys are concatenated values which are different for every entity but still they are being stored in the the same table and the same attribute (pk/sk).

[chemzo]

Thank you @zirkelc

The Human Resources example has 5 GSIs and I need to declare them in the DynamoDB table definition in order for the indexes to work, don't I?

But in the table definition for that example I only have 1 GSI: gsi1pk-gsi1sk-index (and the dynamodb table is named differently than it should: "TableName": "electro" instead of: const table = "projectmanagement";)
https://electrodb.dev/en/examples/human-resources

So I am a bit confused..