Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Inconsistent behaviour between CLI and Explorer when specifying equality predicate on WHERE clause #129

Closed
prrao87 opened this issue Mar 30, 2024 · 8 comments · Fixed by kuzudb/kuzu#3473
Closed

Inconsistent behaviour between CLI and Explorer when specifying equality predicate on WHERE clause #129

prrao87 opened this issue Mar 30, 2024 · 8 comments · Fixed by kuzudb/kuzu#3473
Assignees
@mewim
Labels
bug Something isn't working invalid This doesn't seem right

Comments

@prrao87
Copy link
Member

prrao87 commented Mar 30, 2024 •
edited

This is likely important functionality that's missing (or a bug) in the explorer.

  • Kùzu and explorer version: 0.3.2.
  • Tested on the demo dataset

The following query works in the CLI and in the Python client (i.e., the core is behaving as expected)

MATCH (a:User)-[e:Follows]->(:User {name: "Karissa"})
RETURN a.name AS follower, e.since AS follows_since;

Returns a valid result in Python:

┌──────────┬───────────────┐
│ follower ┆ follows_since │
│ ---      ┆ ---           │
│ str      ┆ i64           │
╞══════════╪═══════════════╡
│ Adam     ┆ 2020          │
└──────────┴───────────────┘

And also in the CLI:

kuzu>  MATCH (a:User)-[e:Follows ]->(:User {name: "Karissa"})
..>        RETURN a.name AS follower, e.since AS follows_since;
----------------------------
| follower | follows_since |
----------------------------
| Adam     | 2020          |
----------------------------
(1 tuple)
(2 columns)
Time: 0.67ms (compiling), 2.68ms (executing)

However, when the same query is run in Kùzu explorer, it doesn't return anything.

image

I even tested the same query with the WHERE clause, and the results are not consistent between the CLI/client API and Explorer.

MATCH (a:User)-[e:Follows]->(b:User)
WHERE b.name = "Karissa"
RETURN a.name AS follower, e.since AS follows_since;
image

Considering that the explorer uses the Node.js client under the hood, do you think something is off with the query parsing when there are predicates on properties there?

I've only tested via the CLI and the Python client, and they both work as expected, so it's something happening that's specific to the Explorer.
@prrao87 prrao87 added bug Something isn't working high-priority Extra attention is needed invalid This doesn't seem right labels Mar 30, 2024
@prrao87 prrao87 changed the title Inconsistent behaviour between CLI and Explorer when specifying equality predicate or WHERE clause Inconsistent behaviour between CLI and Explorer when specifying equality predicate on WHERE clause Mar 31, 2024
@mewim
Copy link
Contributor

mewim commented Apr 1, 2024 •
edited

It seems I cannot reproduce this bug:

Steps I tried:

  • Launch Explorer without a database: docker run -p 8000:8000 --pull=always --rm kuzudb/explorer:latest
  • Load Demo data with Explorer:
Screenshot 2024-04-01 at 7 40 51 PM

Query 1:
Screenshot 2024-04-01 at 7 41 39 PM
Query 2:
Screenshot 2024-04-01 at 7 42 15 PM

@mewim
Copy link
Contributor

mewim commented Apr 1, 2024 •
edited

If you have loaded the dataset on macOS with CLI/Python API and then launch Explorer against the loaded database, this could be due to kuzudb/kuzu#2943 which has been fixed in kuzudb/kuzu#2952 but does not go into 0.3.x releases due to the storage format change.

@prrao87
Copy link
Member Author

prrao87 commented Apr 1, 2024

Ah, that issue might be the reason. Let's keep this open until we release the next version with the storage format change.

@prrao87 prrao87 removed the high-priority Extra attention is needed label Apr 1, 2024
@mewim
Copy link
Contributor

mewim commented May 8, 2024

@benjaminwinger I revisited this issue for the latest release of kuzu (v0.4.1) and it seems the issue still exists. I loaded demo-db on macOS (as attached) and the query returns empty result in a Linux Docker container. The issue seems to have not much to do with Explorer, as it is reproducible with CLI as well. Could you please look into it?
test_db.zip

@prrao87
Copy link
Member Author

prrao87 commented May 8, 2024

Should we maybe create this as an issue on the Kùzu repo instead?

@mewim
Copy link
Contributor

mewim commented May 8, 2024

Update: this issue seems not reproducible on Linux with x86-64 architecture. When running this query on one of our Linux server, it works fine both locally and in Docker, but when using aarch64 Docker images on Mac with Apple M-series CPU, the issue exists.

@mewim
Copy link
Contributor

mewim commented May 8, 2024

I was also able to reproduce this on an Oracle cloud server with Ampere A1 processor, so this seems to be specific to aarch64 architecture.

@benjaminwinger
Copy link

benjaminwinger commented May 9, 2024 •
edited

I don't think this is limited to ARM architectures. I created a branch off v0.4.1 which validates the hash index entries: kuzudb/kuzu@8cfcbe5 (and also fixes some uninitialized data which made direct comparisons of the hash index files more difficult) and ended up with the following issues when opening the above database on x86_64 linux:

Fingerprint for key Zhang in slot 28 was 3 but 166 was expected!
Primary slot ID for key Zhang was calculated to be 16 but the key was stored in slot 28
Fingerprint for key Noura in slot 30 was 112 but 114 was expected!
Primary slot ID for key Noura was calculated to be 9 but the key was stored in slot 30
Fingerprint for key Karissa in slot 14 was 25 but 187 was expected!
Primary slot ID for key Karissa was calculated to be 27 but the key was stored in slot 14
Fingerprint for key Guelph in slot 20 was 60 but 3 was expected!
Primary slot ID for key Guelph was calculated to be 6 but the key was stored in slot 20

Notice that Adam is not mentioned, so it's pure coincidence that the query is succeeding for that key on linux.
It does look like the hashes still aren't functioning the same on the different platforms. Edit: it's Karissa that the query should be looking up using the hash table, and now I'm reproducing it on Linux x86_64 (I'm fairly sure the query succeeded the first time I tried, but regardless, there's clearly something wrong with the hashing on macos)

Update: I can reproduce this with the pre-built 0.4.1 binaries, but not when compiling from scratch. This makes debugging somewhat difficult

This was referenced May 10, 2024
Merged
Merged
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mewim mewim

Labels
bug Something isn't working invalid This doesn't seem right
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fix string hash and add more hash tests kuzudb/kuzu
3 participants
@benjaminwinger @mewim @prrao87