-
Notifications
You must be signed in to change notification settings - Fork 18
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
Conditional updates? #30
Comments
Currently not! but as you can imagine, you can do
instead of B)
Now,
which is a "HUGE" work. https://github.com/typeorm/typeorm does pretty similar thing, but it is truly enormous amount of code to support all that operators and condition The core value I really want to keep on this library is safely typed easy-to-use, fully typed typescript ORM for DynamoDB. if there is a way to keep that and pursue this feature, I'm more than happy to do that. but unfortunately, it seems like pretty hard for now. Small trick my team use on this kinda matter, mostly for massive migration script, |
Hey, Thanks for your excellent reply! Really helpful 😄 Im not sure I follow your consistency argument however as I understand it the purpose of conditional writes / updates is to perform atomic operations for the use of transactions (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/WorkingWithItems.html#WorkingWithItems.ConditionalUpdate) this is the main purpose we are requiring it for. As far as I understand it, in your example A) that operation is handling on your own server not on the DynamoDB service thus it isnt atomic? Thus its no good for transactions. If I understand it correctly your example B) would solve it (if it operates on the DynamoDB server) but as you say, it breaks type safefy which is really what you want to avoid. Another library (https://github.com/lucasmafra/type-dynamo) handles it in an interesting way:
Thoughts? |
Hm I mean it is "Atomic" in a sense that "write" won't happen if the given record is failed to meet given condition at that point Thus the possible outcomes of conditional write are There is no case like "Lock the record while I'm saving this and next person can change it" From the AWS doc example,
In this example, if you're looking for an ability to make user B "fails" conditional update is what you looking for. but I'm just wondering, A) in this case, is it really what you want to user B to "Fail"? If you have real-life example for this application, please let me know! it seems like this kinda makes sense on really specific use cases? but I'm not sure that's even kind of cases that should be done with DynamoDB If it seems like pretty common and meaningful for a lot of cases without requiring complicated typing, i'd surely support this. For example, implementation like
(All attributes of OldRecord will be used for Condtition) wouldn't break anything and pretty staightforward to implement. |
Again thanks for your awesome reply.
Yes this is what im looking for.
Well basically we need it to "fake" transactions by using a "lastUpdatedAt" field on the row. So we first query to return the document then submit the update with the condition that the "lastUpdatedAt" must not have changed. Otherwise we can backout of whatever transaction we were doing.
We are using serverless which imposes some rather severe restrictions on DB choices, so Dynamo is probably our only choice right now. |
👌 that could be meaningful use case l guess. i'd consider supporting
having one key (updatedAt / createdAt ..etc) for avoiding overriding, but that only :) |
Cool :) Tho I think maybe you might want to support a more general case:
Or something like that, im not massively familiar with how DynamoDB conditional writes work yet. Type-dynamo has an interesting functional way of doing it that still keeps it typesafe by using [keys of] dynamoose handles it in a non-type-safe way (https://dynamoosejs.com/api#model):
|
Yeah checking attribute names are valid or not is totally possible. that could be handled by keysof (not perfectly but mostly, since it's would let user to put "virtual" attributes like it's that currently there is no way to check typings for that variable but anyway. as long as this not goes crazy flexible complicated condition, I'd do consider implementing this. But as a start, i'd love to focus on ["lastUpdatedAt", "==", 100] / ["lastUpdatedAt", "!==", 100] only. And if it needs to be more complicated than that, as I mentioned earlier, I strongly recommend to not use DynamoDB. Cloud-based freely scalable RDS like Aurora is really best to fit those kinda usage I've been migrating the whole system to serverless for about 1.5 years, and the big lesson was that RDS + Serverless could work totally fine also :) We did make mistakes of trying to put everything on DynamoDB also, which I can assure, doesn't work for "everything" ANYWAY. I'll keep updating this issue |
Hello there, I'm actively working on this feature. Anyway, I'd like to share the reason why i decided to implement this functionality: First, Orphaned/Incomplete item. These issues can be resolved by using Current design is similar to TypeORM and most of operators will be supported even we don't need other operators. For example: // UpdateItem calls
await Card.primaryKey.update(12345, { likesCount: ["ADD", 1] }, {
condition: { id: attributeExists() } ,
});
// PutItem calls
const card = new Card();
await card.save({ condition: { id: attributeNotExists() } });
// PutItem calls
await card = new Card();
await Card.writer.put(card, {
condition: { id: attributeNotExists() },
});
// Complex conditions
await card.save({
// same as: (status = 0 AND likesCount > 0) OR (userId IN (1,2,3,4))
conditions: [
{ status: Equal(CardStatus.ACTIVE), likesCount: GreaterThan(0) },
{ userId: In([1,2, 3, 4]) },
],
}); |
I forked dynamo-types and made a lot of changes, my fork called Dyngoose supports conditional writes and is somewhat compatible with dynamo-types. |
@mikecann as of transaction - https://aws.amazon.com/blogs/aws/new-amazon-dynamodb-transactions/ it's actually being supported as native API. will work on to support this soon |
Hey, I cant see it anywhere but does this lib support conditional updates?
The text was updated successfully, but these errors were encountered: