This week, we keep working on the Yaxing’s example with more challenge queries. We came up with a more complex query to test the power of general RPQ/2. The query is like this: “Now we need to run a new version of tool “ArcGIS”, which data in csv format should be updated? And after we fix the problem, which processes should be rerun?” The complexity of the query is that the path start from a node, go through a particular label and end with a certain type of nodes. Our RPQ system can totally answer that and visualize it in a nice graph. At the same time, in order to make the graph neater, we shorten the label on the edge and put a legend on the graph, along with couple of improvements to make it nicer.
Adding CRPQ to our existing engine is not trivial and a little bit redundant. since it’s not a good idea to get multiple separated results from the engine and write another program to combine the results. And Datalog is known to be a logic programming language or a way to write down difinition. Plus, we found some bugs on the Postgres RPQ enigne, e.g. if there are mutiple * symbols, the result is incorrect. So we decide to use Datalog completely to implement CRPQ. Though we need to somehow start over to Do RPQ/2, RPQ/4 then CRPQ, the datalog version will be more efficient and easier to understand. We have written down the RPQ/4 rules in datalog, the remaining part is to write a program for it. Hopefully next week, CRPQ would be out.