LIMIT, OFFSET have weird behavior
krerkkiat opened this issue · comments
Platform: Windows
Docker Engine Version: 18.09.7
sourced version: v0.15.1 build 08-27-2019_12_51_42
srcd/gitbase image version: v0.23.1
The following are listing of records to show that there are at least 5 records.
MySQL [(none)]> SELECT commit_hash, file_path FROM commit_files WHERE commit_hash="0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9" ORDER BY file_path LIMIT 5;
+------------------------------------------+-------------------------------------------+
| commit_hash | file_path |
+------------------------------------------+-------------------------------------------+
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .clang-format |
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/bug_report.md |
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/feature_request.md |
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/issues.md |
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .gitignore |
+------------------------------------------+-------------------------------------------+
5 rows in set (16.62 sec)
Using LIMIT with 0 offset work as expected
MySQL [(none)]> SELECT commit_hash, file_path FROM commit_files WHERE commit_hash="0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9" ORDER BY file_path LIMIT 0, 3;
+------------------------------------------+-------------------------------------------+
| commit_hash | file_path |
+------------------------------------------+-------------------------------------------+
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .clang-format |
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/bug_report.md |
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/feature_request.md |
+------------------------------------------+-------------------------------------------+
3 rows in set (13.83 sec)
Using LIMIT with n OFFSET does not seem to work properly
MySQL [(none)]> SELECT commit_hash, file_path FROM commit_files WHERE commit_hash="0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9" ORDER BY file_path LIMIT 1, 3;
+------------------------------------------+-------------------------------------------+
| commit_hash | file_path |
+------------------------------------------+-------------------------------------------+
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/bug_report.md |
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/feature_request.md |
+------------------------------------------+-------------------------------------------+
2 rows in set (14.16 sec)
If a query that has LIMIT 1, 3 is run on any database, the result will be 3 rows (provided that the query without the LIMIT produces more than 3 rows). It is clear from the beginning as well that this query can produce at least 5 rows of the result.
Some more examples
MySQL [(none)]> SELECT commit_hash, file_path FROM commit_files WHERE commit_hash="0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9" ORDER BY file_path LIMIT 2, 3;
+------------------------------------------+-------------------------------------------+
| commit_hash | file_path |
+------------------------------------------+-------------------------------------------+
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/feature_request.md |
+------------------------------------------+-------------------------------------------+
1 row in set (15.53 sec)
Three rows are expected in this case as well.
MySQL [(none)]> SELECT commit_hash, file_path FROM commit_files WHERE commit_hash="0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9" ORDER BY file_path LIMIT 3 OFFSET 2;
+------------------------------------------+-------------------------------------------+
| commit_hash | file_path |
+------------------------------------------+-------------------------------------------+
| 0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9 | .github/ISSUE_TEMPLATE/feature_request.md |
+------------------------------------------+-------------------------------------------+
1 row in set (14.58 sec)
This query is the same query as the one before it. The only different is the way LIMIT and OFFSET are specified.
MySQL [(none)]> SELECT commit_hash, file_path FROM commit_files WHERE commit_hash="0ae3c1cc5e6677be2506a3a80a063d4e72f89cd9" ORDER BY file_path LIMIT 3 OFFSET 3;
Empty set (13.32 sec)
The result should still have at least two rows.
Thank you for reporting! we'll take a look as soon as we can.
I have been able to reproduce this error with the version you mention. However, I cannot reproduce it with the latest release of gitbase. Can you please try with the latest version (v0.24.0-beta3 at the time)?
Even if it's a beta, you should use the latest version when possible, as it may contain many bugfixes.
I am currently using sourced CE, so I change the docker-compose.yml to use v0.24.0-beta3 as you suggested. However, the problem is still there.
To be fair, I am not sure if change the version of the image is all I need or there are some other places that need an update too.
@krerkkiat did you rebuild the images before starting CE again? If you're using docker-compose up it doesn't do it by default.
Try:
docker-compose up --force-recreate --build -d
I used the web interface to test the query and it still has some weird behavior. e.g.
LIMIT 5, 1gives 5 rows instead of 1 row.LIMIT 1, 5gives 1 rows instead of 5 rows.LIMIT 1 OFFSET 5works as expected.LIMIT 5 OFFSET 1works as expected.
So the web interface's result throw me off a little bit. The direct query (via sourced sql) is working as expected though.
edit:
I will try rebuild images as you suggest next.
What I did to update image is sourced prune then sourced init local <path> with modified docker-compose.yml, and that produces the weird result when a query is executed via web interface.
Then I tried your method, but I cloud not figured out how to load data into the server.
@krerkkiat LIMIT 5, 1 means LIMIT 5 OFFSET 1, so that's why it returns 5 rows instead of 1. Same for LIMIT 1, 5
Interesting. What I found so far for SQL syntax suggested that LIMIT 5, 1 means LIMIT 1 OFFSET 5. So, in this case it is different then.
e.g. http://www.sqltutorial.org/sql-limit/
edit: That specific abbreviation that I found is just for MySQL, right? If that is the case then it make sense.
Just tested with current master and you're right LIMIT 5,1 means LIMIT 1 OFFSET 5. But I can't reproduce the error in current master and is working according to how it should.