Hi everyone,<\/p>\n
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: “<\/strong>Now we need to run a new version of tool \u201cArcGIS\u201d, 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\u00a0certain\u00a0type 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.<\/p>\n Adding CRPQ to our existing engine is not trivial and a little bit\u00a0redundant. since it’s not a good idea to get\u00a0multiple\u00a0separated results from the engine and write another program to combine the results. And\u00a0Datalog is known to be a logic\u00a0programming\u00a0language or a way to write down difinition.\u00a0Plus, 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\u00a0efficient\u00a0and\u00a0easier\u00a0to 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.<\/p>\n <\/p>\n Best, Hi everyone, 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 \u201cArcGIS\u201d, which data in csv Continue reading Week 7 Report<\/span>
\nTianhong<\/p>\n","protected":false},"excerpt":{"rendered":"