You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which service(blob, file, queue, table) does this issue concern?
table
Which version of the Azurite was used?
3.29
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
npm and ran code from github main
What's the Node.js version?
9.8.1
What problem was encountered?
GET /devstoreaccount1/table()?$filter=PartitionKey%20ne%20%27Current%27%20and%20PlayIndex%20ge%2012L%20and%20PlayIndex%20lt%2013L HTTP/1.1
I do a query and find elements with playindex 12 (expected) but also 120-129 (wrong). This works perfectly fine against azure storage account so is specific to azurite. Also works fine if you drop the L from the query so it treats params as Int32.
Steps to reproduce the issue?
Add entities with a Int64 column and increment +1 each time to new column (add loads) then do a query for less than or equal to a small number and you'll get the extra results.
Have you found a mitigation/solution?
Workaround - dropping the L's off the query does the trick but fearful I may run into trouble on bigger numbers.
Solution attempt - I've had a dig around the code and it is because the filter value 13 is stored as a string as opposed to numeric so I ended up here:
QueryParser.ts
private visitNumber(): IQueryNode {
const token = this.tokens.next(t => t.kind === "number") || this.throwUnexpectedToken("number");
if (token.value!.endsWith("L")) {
// This is a "long" number, which should be represented by its string equivalent
return new ConstantNode(token.value!.substring(0, token.value!.length - 1));
} else {
return new ConstantNode(parseFloat(token.value!));
}
}
Adding a parseInt around the substring makes my case work correctly but the comment above suggests this is wrong, probably due to node numbers being smaller than int64. To try and fix I believe would entail a large code change that unfortunately I don't have the time for.
The text was updated successfully, but these errors were encountered:
Which service(blob, file, queue, table) does this issue concern?
table
Which version of the Azurite was used?
3.29
Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)
npm and ran code from github main
What's the Node.js version?
9.8.1
What problem was encountered?
GET /devstoreaccount1/table()?$filter=PartitionKey%20ne%20%27Current%27%20and%20PlayIndex%20ge%2012L%20and%20PlayIndex%20lt%2013L HTTP/1.1
I do a query and find elements with playindex 12 (expected) but also 120-129 (wrong). This works perfectly fine against azure storage account so is specific to azurite. Also works fine if you drop the L from the query so it treats params as Int32.
Steps to reproduce the issue?
Add entities with a Int64 column and increment +1 each time to new column (add loads) then do a query for less than or equal to a small number and you'll get the extra results.
Have you found a mitigation/solution?
Workaround - dropping the L's off the query does the trick but fearful I may run into trouble on bigger numbers.
Solution attempt - I've had a dig around the code and it is because the filter value 13 is stored as a string as opposed to numeric so I ended up here:
QueryParser.ts
Adding a parseInt around the substring makes my case work correctly but the comment above suggests this is wrong, probably due to node numbers being smaller than int64. To try and fix I believe would entail a large code change that unfortunately I don't have the time for.
The text was updated successfully, but these errors were encountered: