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.

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

Wrong uniqueness constraint for callables table #23

Closed
gousiosg opened this issue Apr 30, 2020 · 0 comments
Closed

Wrong uniqueness constraint for callables table #23

gousiosg opened this issue Apr 30, 2020 · 0 comments
Assignees

Comments

@gousiosg
Copy link
Contributor

I think the uniqueness constraints for table callables is wrong. Let's take
callable 331721314 (current Java database) and see some info for it:

select p.package_name, pv.version, pv.created_at, m.namespace, c.fasten_uri
from packages p
  join package_versions pv on p.id = pv.package_id
  join modules m on pv.id = m.package_version_id
  join callables c on c.module_id = m.id
where c.id = 331721314;

org.neo4j.neo4j-graph-algo | 3.5.1   | 2018-12-20 13:27:36 | /org.neo4j.graphalgo.impl.shortestpath/Dijkstra$DijkstraIterator | /org.neo4j.graphalgo.impl.shortestpath/Dijkstra$DijkstraIterator.InitQueue()%2Fjava.lang%2FVoidType

This corresponds to the following code: https://github.com/neo4j/neo4j/blob/3.5/community/graph-algo/src/main/java/org/neo4j/graphalgo/impl/shortestpath/Dijkstra.java#L223

Then, we take the edges:

select e.source_id, e.target_id, c.fasten_uri 
from edges e join callables c on c.id = e.target_id
where source_id = 331721314;

 331721314 |  15052438 | /org.neo4j.graphalgo.impl.shortestpath/DijkstraPriorityQueueFibonacciImpl.DijkstraPriorityQueueFibonacciImpl(%2Fjava.util%2FComparator)%2Fjava.lang%2FVoidType
 331721314 |  15052441 | /org.neo4j.graphalgo.impl.shortestpath/DijkstraPriorityQueueFibonacciImpl.insertValue(%2Forg.neo4j.graphdb%2FNode,%2Fjava.lang%2FObject)%2Fjava.lang%2FVoidType
 331721314 |  15052299 | /org.neo4j.graphalgo.impl.shortestpath/DijkstraPriorityQueueImpl.insertValue(%2Forg.neo4j.graphdb%2FNode,%2Fjava.lang%2FObject)%2Fjava.lang%2FVoidType
 331721314 |         1 | ///java.lang/NullPointerException.NullPointerException()VoidType
 331721314 |     16485 | ///java.util/HashMap.put(%2Fjava.lang%2FObject,%2Fjava.lang%2FObject)%2Fjava.lang%2FObject

Node 16485 corresponds to line 227. Node 1 I don't know, but I suspect it is thrown somewhere. Nodes 15052438 is line 225 whereas 15052299 and 15052441 are the result of a virtual dispatch on line 226. This looks good, until...

select p.package_name, pv.version, pv.created_at, m.namespace, c.fasten_uri
from packages p
  join package_versions pv on p.id = pv.package_id
  join modules m on pv.id = m.package_version_id
  join callables c on c.module_id = m.id
where c.id = 15052299;

org.neo4j.neo4j-graph-algo | 3.3.0-alpha06 | 2017-08-17 10:12:43 | /org.neo4j.graphalgo.impl.shortestpath/DijkstraPriorityQueueImpl | /org.neo4j.graphalgo.impl.shortestpath/DijkstraPriorityQueueImpl.insertValue(%2Forg.neo4j.graphdb%2FNode,%2Fjava.lang%2FObject)%2Fjava.lang%2FVoidType

The version of the function the callgraph points to is different (older).

I suspect this is because during upsert we only query the uniquness of a FASTEN URI that does not include a version number. So I 'd like to suggest that we change the uniqueness constraint to include the field module_id, which is already versioned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants