-
Notifications
You must be signed in to change notification settings - Fork 871
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
A* SQL function returns paths of increasing length for consecutive, identical queries #7103
Comments
Hi @martineutinger , @luigidellaquila |
Thank you @saeedtabrizi, I'll check it as well Thanks! Luigi |
Hi @martineutinger , @luigidellaquila |
Great, thank you very much @saeedtabrizi ! Looking forward to the pr! Thanks Luigi |
-fix null checking in astar function . - add toCalendar method as we discussed on Better support for time expression orientechnologies#7081. - add some test cases for toCalendar Method . (need to be documented) .
@luigidellaquila the bugs fixed now . |
Thank you @saeedtabrizi. So does that mean the single-astar-instance-per-server is by design? |
Dear @martineutinger , Short answer is Yes in the current version . but i planned to add and implement some useful and more efficient path finding functions like the Block A* , Hybrid A* , CH , CRP for OrientDB asap . I'm glad if i hear from @lvca , @luigidellaquila and i create an issue for proposal path-finding . |
+100! |
I just pushed a fix for this. Thank you very much @saeedtabrizi for the contribution! Luigi |
@luigidellaquila Thanks to solve the root of problem . |
Noted in the Release Notes |
-fix null checking in astar function . - add toCalendar method as we discussed on Better support for time expression orientechnologies#7081. - add some test cases for toCalendar Method . (need to be documented) .
-fix null checking in astar function . - add toCalendar method as we discussed on Better support for time expression orientechnologies#7081. - add some test cases for toCalendar Method . (need to be documented) .
OrientDB Version, operating system, or hardware.
Operating System
Expected behavior and actual behavior
When sending the same query (e.g. 'SELECT astar(#23:19965, #23:19187, 'length')') more than once, only the first result is correct. The consecutive results are longer and longer paths until it seems to either plateau or return no path at all.
So e.g. the shortest path contains 5 nodes.
The first query would return the 5 nodes. The second would return 10. Then 17. And then it returns 21 for every query past that point.
Steps to reproduce the problem
Possible solutions
The problem seems to be, that in com.orientechnologies.orient.graph.sql.functions.OSQLFunctionAstar
'PriorityQueue open' and 'Set closedSet' are carried over from the last execution of the algorithm.
It seems like ...
... either .clear() should be called for 'open' and 'closedSet' before each execution
... or a new instance of OSQLFunctionAstar should be created, every time the function is executed.
Misc
This is not the case with Dijkstra's algorithm, because a new instance of A* is created each time.
The text was updated successfully, but these errors were encountered: