-
Notifications
You must be signed in to change notification settings - Fork 107
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
Add TransactWriteItems #174
base: main
Are you sure you want to change the base?
Conversation
…ransactWriteItems
…ransactWriteItems � Conflicts: � package-lock.json
Update readme, links
Testing locally, all these took <1s to run
Add some verbose logging
… interface Update readme
n0286293 seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor comments mostly
request(opts(target, data), function (err, res) { | ||
if (err) return done(err) | ||
if (typeof res.body !== 'object') { | ||
return done(new Error('Not JSON: ' + res.body)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
super-minor: I'd use a template literal instead
children: 'AttrStruct<ValueStruct>', | ||
}, | ||
ExpressionAttributeNames: { | ||
type: 'Map<java.lang.String>', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is a Java reference an artefact of the validation library?
It's odd to see it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DynamoDB's java leaks through in its validation, I think this is expected.
children: 'AttrStruct<ValueStruct>', | ||
}, | ||
ExpressionAttributeNames: { | ||
type: 'Map<java.lang.String>', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto.
msg = validations.validateAttributeValue(request.Put.Item[key]) | ||
if (msg) return msg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
subject to style debate:
msg = validations.validateAttributeValue(request.Put.Item[key]) | |
if (msg) return msg | |
if (msg = validations.validateAttributeValue(request.Put.Item[key])) | |
return msg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those inline assignments within conditionals are clever but are also imo a bit unusual, and certainly more difficult to debug later. They also blow up eslint:recommended
on no-cond-assign.
var i, request, msg, key | ||
for (i = 0; i < data.TransactItems.length; i++) { | ||
request = data.TransactItems[i] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
subject to style debate, or maybe performance?
I'd rather move the variable declaration into the loop:
var i, request, msg, key | |
for (i = 0; i < data.TransactItems.length; i++) { | |
request = data.TransactItems[i] | |
for (const request of data.TransactItems) { | |
let msg; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree
var requests = [], i | ||
for (i = 0; i < 26; i++) { | ||
requests.push(i % 2 ? { Delete: { Key: { a: { S: String(i) } } } } : { Put: { Item: { a: { S: String(i) } } } }) | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe something like this:
var requests = [], i | |
for (i = 0; i < 26; i++) { | |
requests.push(i % 2 ? { Delete: { Key: { a: { S: String(i) } } } } : { Put: { Item: { a: { S: String(i) } } } }) | |
} | |
const requests = new Array(26).fill(null).map(() => ({...})) |
assertTransactionCanceled = helpers.assertTransactionCanceled.bind(null, target), | ||
assertNotFound = helpers.assertNotFound.bind(null, target) | ||
|
||
describe('transactWriteItem', function () { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file really needs a review, specifically that correct exceptions are raised in corner cases, in a way that dynalite behaviour matches AWS dynamodb.
I'm flagging it here because GitHub hides this diff by default calling it "too large".
async.each(operationsbyTable, function ([ tableName, ops ], callback) { | ||
var itemDb = store.getItemDb(tableName) | ||
|
||
store.getTable(tableName, function (err, table) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need to dig into this @jpeterschmidt – do you recall what was intended here? It looks like the callback can be called in a variety of different ways and may be called multiple times.
For example, the callback on L29 may be called many times across the indexUpdates
array, and will not cancel operations. And then itemDb.batch
on L32 may also be calling the same callback at the same time. Moreover, if there's an error it will call said callback twice, with the results in the error position of the errback.
children: 'AttrStruct<ValueStruct>', | ||
}, | ||
ExpressionAttributeNames: { | ||
type: 'Map<java.lang.String>', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DynamoDB's java leaks through in its validation, I think this is expected.
var i, request, msg, key | ||
for (i = 0; i < data.TransactItems.length; i++) { | ||
request = data.TransactItems[i] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree
msg = validations.validateAttributeValue(request.Put.Item[key]) | ||
if (msg) return msg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those inline assignments within conditionals are clever but are also imo a bit unusual, and certainly more difficult to debug later. They also blow up eslint:recommended
on no-cond-assign.
@ryanblock What is the must fix here to get this merged? If we are just a few hours of work away I'd be happy pitch in. |
@jpshack-at-palomar please read my comments above; this PR has fundamental issues with how continuation passing works, and it cannot be merged in its current state. As a programmer, I do not feel confident making claims that anything is a few hours of work away, let alone something as complex as this. I was hoping the author would help us get this PR into shape, but since we haven't heard back my plan has been to hopefully snag a few bits here and there, but probably rewrite. As ever, I'd be happy for someone in the community to start work on a fresh PR. |
Thank you for helping out! ✨
We really appreciate your commitment to improving Dynalite
To maintain a high standard of quality in our releases, before merging every pull request we ask that you've completed the following:
main
npm it
from the repo root)changelog.md
Please also be sure to completed the CLA (if you haven't already).
Learn more about contributing to Architect here.
Thanks again!