Implement a querying mechanism for loaded Graph

[xadahiya]

Write a querying mechanism to extract information from the graph loaded in memory. Redis uses openCypher by default. I'm not sure if redis-py can be used for querying purposes, explore different options and write their pros and cons below.
Some helpful resources -

• https://oss.redislabs.com/redisgraph/design/#graph-representation-hexastore
• http://pythonik.blogspot.com/2010/11/redis-patterns-search.html

[sandeepsajan0]

I think we can access the redisgraph's all functionality with its any client https://oss.redislabs.com/redisgraph/#using-redis-graph
I will take some help with these commands https://oss.redislabs.com/redisgraph/commands/#query-language.

[sandeepsajan0]

Can you elaborate for me a bit with an example that how I should proceed for querying mechanism?
And also suggests some things which should be mind for querying.

[xadahiya]

And also suggests some things which should be mind for querying.

Consider the drone API example. User can query for all drones with max_speed > 100 or drones with battery > 30%.
The user should also be able to query all API endpoints, class endpoints, collection endpoints etc.
He should also be able to view all supported properties for each endpoint object for example in case of drone demo he should be able to query and view all supportedProperties and supportedOperations for the drone and all other endpoints.

Note - We'll also need to add functionality to make requests to the server in order to add/modify/delete data but this can be done later. You should design the agent keeping this in mind though.

The querying format and implementation part is up to you. Do some research and discuss possible options or ideas you have in mind here.

[sandeepsajan0]

Querying format(user input):

For querying endpoints- url:endpoint, url:entrypoint, url:endpoint:id and etc like these(here id is just refer to the member of any collection endpoint).

For querying operation or property- url:endpoint:operation, url:endpoint:property, url:endpoint:propValue, and same for id(members) and etc like these( operation = supportedOperation and property = supportedProperty and propValue = supportedProperty with its values).

For querying with comparison(like max_speed > 100)- url:endpoint:propCompare, url:endpoint:propCompare1:and:propComp2, and more like these(propCompare can be stored in a list with and and or in same order as user input).

Benefit of this format:

1. We need url for fetch or load the information.
2. We can also get url for any endpoint with the help of url and endpoint.
3. We can easily handle with the comparison of supported property like max_speed > 100 and other.

Execution process:
Every time when user querying, we have a check for the same url and endpoint of its existence in Redis. If it exists in Redis then we can direct query from Redis but if it does not exist in Redis we have load data from the server to Redis for the same endpoint and then query from the Redis.

Please share your opinion on this and suggest required changes.

[xadahiya]

For querying endpoints- url:endpoint, url:entrypoint, url:endpoint:id and etc like these(here id is just refer to the member of any collection endpoint).
For querying operation or property- url:endpoint:operation, url:endpoint:property, url:endpoint:propValue, and same for id(members) and etc like these( operation = supportedOperation and property = supportedProperty and propValue = supportedProperty with its values).

The url and entrypoint will be provided to the agent during the initialization. The user should not need to provide url and entrypoint information everytime. He should be able to query things about the API structure using simple commands like show endpoints, show collection endpoints, show class endpoints etc.
For supported operations you can use something like show <endpoint_name> supportedOperations and the same goes for supportedProperties.

For querying with comparison(like max_speed > 100)- url:endpoint:propCompare, url:endpoint:propCompare1:and:propComp2, and more like these(propCompare can be stored in a list with and and or in same order as user input).

Same goes for this as well. The user should not need to provide url: endpoint for every query. If he has this information then he can directly fetch the data from the server.
The idea here is that the user should be able to query anything about the data present in the server without needing much knowledge.
For example: Consider the Drone API, suppose the user wants to get every HttpApiLog where status is 200 and drone ID is 2 then he should be able to do this without needing much knowledge about the server itself. He can query the supported properties first and then use those in any combination he wants.

Devise a set of rules and query formats that you'll be implementing and post them here with examples. Imagine you're the user using the agent and write down what queries you might need, what will make things easier and stuff like that.

@Mec-iS ^^ Any suggestions?

[xadahiya]

Implemented in #23