kuzudb / kuzu

Embeddable property graph database management system built for query speed and scalability. Implements Cypher.
https://kuzudb.com/
MIT License
1.41k stars 99 forks source link

Getting Opposite (Non Existant) relations when using SHORTEST PATH queries #3169

Closed johnsmith765 closed 4 months ago

johnsmith765 commented 7 months ago

I have twitter related data in my database which includes Tweets, Users, Hashtags etc , and I have relations that include Posts (User Posting a tweet), Mentions (Tweet mentioning a user), Tags (Tweet tagging a hashtag). Here are the relation tables

CREATE REL TABLE POSTS(FROM User TO Tweet)
CREATE REL TABLE MENTIONS(FROM Tweet TO User)
CREATE REL TABLE TAGS(FROM Tweet TO Hashtag)

When I run a query without path, I get correct results, for example

match (n:User {screen_name: $screen_name})-[r]-(m)
RETURN n,r,m,
LIMIT 10`

This gives my correct direction of edges, But when I try to find a shortest path between two users using the following query,

MATCH p = (u:User {screen_name: $source})-[r* ALL SHORTEST 1..30]-(t:User {screen_name: $target}) 
RETURN nodes(p) as nodes, rels(p) as edges LIMIT 5;

I get incorrect/opposite direction of edges, for example, Tweet posting a User, User mentioning a Tweet, But no rel table with such directions exists I am using Node.js library to query. Not sure if it is a bug or I am doing it wrong. Need some help. Best regards

andyfengHKU commented 7 months ago

Hi @johnsmith765,

I wouldn't say this is a bug because if the relationship shows tweet -> user, it means we calculate internally from tweet with a backward adjacency list that points to user. It doesn't not imply the relationship is from tweet to user.

On the other hand, I do realize this could be confusing and inconsistent with Neo4j behaviour. We have a similar issue (#3166 ) posted by our other users. I'll fix this issue and keep u updated.

andyfengHKU commented 4 months ago

Apparently I was wrong, the relationship was indeed returned in the wrong direction. This is now fixed in #3765.

Sorry for the confusion.