-
Notifications
You must be signed in to change notification settings - Fork 196
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussing current ex.Table.insert()
behaviour
#2437
Comments
+1 that the current I think the closest thing the current abstraction was targeting is a I also think this is distinct from a |
@MarkMcCulloh The way I agree that we should make a clear distinction between a key-value database (DynamoDB) and a document-oriented database (DocumentDB) and have two separate classes for them. I think the current behaviour of |
I would like to offer a different approach: holding off abstracting the DB (for now), I see a couple of advantages:
I would also suggest to move this class (and redis) to a bring db;
new db.Redis(); // OSS on docker | elasticCache
new db.DynamoDb(); // dynamodb-local | DynamoDb
new db.PostgressSql(); // OSS on docker | Aurora-postgress
new db.MySql(); // OSS on docker | Aurora-SQL |
Hi, This issue hasn't seen activity in 60 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. |
Keep. |
cloud.Table.insert()
behaviourex.Table.insert()
behaviour
Hi, This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. |
Hi, This issue hasn't seen activity in 90 days. Therefore, we are marking this issue as stale for now. It will be closed after 7 days. |
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 newcloud.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 toDynamoDB::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 acloud.Table
actually represents.Implementation Notes
No response
Component
No response
Community Notes
The text was updated successfully, but these errors were encountered: