Azure / Azure/Azurite

Table Api Query on Int64 (long) column returning extra results

Open
#2,385 1 comment 0 reactions 0 assignees View on GitHub
table-storage
Dominant language
TypeScript
Stars
2.3k
Forks
393
Avg merge
1d 20h
Merged PRs (30d)
36

Description

### 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.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.