Discussing current `ex.Table.insert()` behaviour

Feature Spec

I think maybe Table alone is a too ambiguous term. Currently you can find the following comment for the class definition: Represents a NoSQL database table that can be used to store and query data.

I think calling it something like KVStore would be more clear, but that's for another thread.

What I wanted to discuss is the fact that currently the insert method expects that a certain column is already defined in the table. What does that mean? It means that when you are creating a new cloud.Table you are effectively forced to provide a schema for your entire table, thus making it similar to a relational db table, which is the total opposite of a NoSQL db table/KV store.

So what happens if you try to insert a row that has an attribute/column which wasn't defined during the table creation?
Error: "key" is not a valid column in the table.

If we agree that cloud.Table gets translated to DynamoDB::Table in AWS, then we should just enforce the definition of the attribute type of the partition key during the table creation, and not the whole schema, because that's the opposite of how a KV store works.

Use Cases

Make insert method consistent with what a cloud.Table actually represents.

Implementation Notes

No response

Component

No response

Community Notes

• Please vote by adding a 👍 reaction to the issue to help us prioritize.
• If you are interested to work on this issue, please leave a comment.

Start by tracing the cloud.Table and ex.Table.insert() APIs, then compare their behavior with the referenced DynamoDB::Table model. Clarify whether creation should require only the partition-key attribute type and whether insert should accept undeclared attributes; the issue is done when the agreed behavior is implemented and covered by tests.