[ 
https://issues.apache.org/jira/browse/S2GRAPH-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16529377#comment-16529377
 ] 

DOYUNG YOON commented on S2GRAPH-229:
-------------------------------------

[~daewon]
I think this is somewhat related to the old issue I created(S2GRAPH-173), with 
a different perspective in mind. 
I am more than happy to work on this with you and please let me know how we are 
going to add this new abstraction.
Following is my simple thought. please let me know what you think.

First, create the common interface on `Step`.
I guess we may research few alternatives while we are defining the interface(I 
am big +1 on using Observable).

Second, try to replace method on S2Graph class using `Step` interface.
I think currently, we do not have any builder to `connect` these `Step`s. It 
would be great if we can provide a way to translate the logical query into the 
tree of `Step`, then provide a single observable that user can subscribe.

Once we are confident that all of the current query features can be replaceable 
, then start adding more steps that can be useful but missed out in current 
s2graph query.




> 'Step' abstraction for combinable queries
> -----------------------------------------
>
>                 Key: S2GRAPH-229
>                 URL: https://issues.apache.org/jira/browse/S2GRAPH-229
>             Project: S2Graph
>          Issue Type: Task
>          Components: s2core
>            Reporter: Daewon Jeong
>            Priority: Minor
>
> Graph Query is a combination of queries of each step.
> For example, 
>   1. you can take a vertex, 
>    2. then bring the edge back with that vertex, 
>    3. get the vertex from the edge, 
>    4. and bring the edge from that vertex.
> The query that is being provided now is not tied to each of the above steps, 
> but is tightly coupled throughout the query.
> Since functions such as filter, transform(group_by, merge), and 
> postprocess(conversion to json/xml) are tightly coupled to the entire query 
> function, 
>  it is difficult to test each function separately. 
> To solve this problem, 
>    1. each step is created as an independent function and 
>    2. the function of assembling each step is separated separately.
> Each step is separated as above, the following functions can be implemented 
> without additional code.
>   ex) In the case of deleteAll, fetch each edge and make delete request 
> again. 
> Implement Prototyping
>     1. For query efficiency, each step implements the function to return 
> Observable.
>     2. Use Observable(RxScala)'s flatMap to connect each step.
> Below is the pseudocode.
> 1. Bringing the edges from the vertex, collect only edges whose score is 0.5 
> and serialize them to Json
> {code:java}
>  val vs: Step[Int, S2VertexLike] = VertexStep()
>  val es: Step[S2VertexLike, S2EdgeLike] = EdgeStep(dir = "OUT")
>  val js: Step[S2EdgeLike, Json] = JsonSerializeStep(limit: 10)
> val q: Observable[Json] = 
>  vs.apply(1) 
>  .flatMap(es)
>  .filter(_.property("score") > 0.5)
>  .flatMap(js)
> {code}
> What to think about.
>     1. The ability to link each step is subject to Observable.
>  - This makes it impossible to draw the connection graph of the Step instead 
> of making the function easier to implement.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to