-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Consume start and end partition and row keys #25293
Conversation
API change check API changes are not detected in this pull request. |
@@ -37,6 +39,28 @@ describe("SAS generation", function () { | |||
assert.equal(tableSas, expectedSas1); | |||
}); | |||
|
|||
it("should generate a SAS token with start partition and row keys", async () => { |
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.
Mocha explicitly states that arrow functions are discouraged, because they cannot access the Mocha context available in this
:
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.
yes, we even have a work item tracking changing arrow functions to regular functions #13005.
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.
Well, I guess today is the day for Tables. I have migrated all the tests from arrow functions to anonymous functions.
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.
Looks good. I added some minor comments
Hello @joheredi! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
Packages impacted by this PR
@azure/data-tables
Issues associated with this PR
#25252
Describe the problem that is addressed by this PR
We accept startPartitionKey, startRowKey, endPartitionKey and endRowKey parameters when generating table sas token. However internally we are ignoring those provided values.
What are the possible designs available to address the problem? If there are more than one possible design, why was the one in this PR chosen?
To fix this problem we simply need to plumb the values through
Are there test cases added in this PR? (If not, why?)
YES
Provide a list of related PRs (if any)
N/A