[jira] [Comment Edited] (S2GRAPH-222) Support Not logical operator in WhereParser.
[
https://issues.apache.org/jira/browse/S2GRAPH-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513352#comment-16513352
]
Daewon Jeong edited comment on S2GRAPH-222 at 6/15/18 5:17 AM:
---
[~steamshon]
I think `Where Parser` should follow the grammar of the where clause of
standard SQL.
If follow the syntax of the standard SQL clause, user can easily predict usage.
I think that the revised contents have been modified well in the parts which
had been previously implemented incorrectly (not the general processing but
specifically the `NOT IN` processing)
But for a more predictable syntax, I think it would be better to implement all
the `NOT condition` clauses of the type supported by the standard SQL.
{code:sql}
NOT condition
{code}
Below is all valid SQL queries.
ex) NOT IN clause
{code:sql}
SELECT Id, CompanyName, City, Country
FROM Supplier
WHERE NOT (Country IN ('USA', 'UK', 'Japan'))
{code}
{code:sql}
SELECT Id, ProductName, UnitPrice
FROM Product
WHERE UnitPrice NOT IN (10,20,30,40,50)
{code}
ex) NOT like
{code:sql}
SELECT *
FROM suppliers
WHERE supplier_name NOT LIKE '%o%';
{code}
{code:sql}
SELECT *
FROM suppliers
WHERE NOT(supplier_name LIKE '%o%');
{code}
link: [http://www.dofactory.com/sql/where-in]
was (Author: daewon):
[~steamshon]
I think `Where Parser` should follow the grammar of the where clause of
standard SQL.
If follow the syntax of the standard SQL clause, user can easily predict usage.
I think that the revised contents have been modified well in the parts which
had been previously implemented incorrectly (not the general processing but
specifically the `NOT IN` processing)
But for a more predictable syntax, I think it would be better to implement all
the `NOT condition` clauses of the type supported by the standard SQL.
> Support Not logical operator in WhereParser.
> -
>
> Key: S2GRAPH-222
> URL: https://issues.apache.org/jira/browse/S2GRAPH-222
> Project: S2Graph
> Issue Type: New Feature
> Components: s2core
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
>
> `And/Or` operator is implemented as a logical operator, but `Not` is not
> implemented in WhereParser.
> This is illustrated by following examples.
> Following query works only because we added hardcoded implementation on `not
> in` as predicates.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "friend_name not in ('steamshon')") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> I believe implementing `Not` as a logical operator is more general, so below
> is my suggestion.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "NOT (friend_name in ('steamshon'))") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> In this way, we don't need to implement not case for all predicates, such as
> `in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (S2GRAPH-222) Support Not logical operator in WhereParser.
[
https://issues.apache.org/jira/browse/S2GRAPH-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513352#comment-16513352
]
Daewon Jeong commented on S2GRAPH-222:
--
[~steamshon]
I think `Where Parser` should follow the grammar of the where clause of
standard SQL.
If follow the syntax of the standard SQL clause, user can easily predict usage.
I think that the revised contents have been modified well in the parts which
had been previously implemented incorrectly (not the general processing but
specifically the `NOT IN` processing)
But for a more predictable syntax, I think it would be better to implement all
the `NOT condition` clauses of the type supported by the standard SQL.
> Support Not logical operator in WhereParser.
> -
>
> Key: S2GRAPH-222
> URL: https://issues.apache.org/jira/browse/S2GRAPH-222
> Project: S2Graph
> Issue Type: New Feature
> Components: s2core
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
>
> `And/Or` operator is implemented as a logical operator, but `Not` is not
> implemented in WhereParser.
> This is illustrated by following examples.
> Following query works only because we added hardcoded implementation on `not
> in` as predicates.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "friend_name not in ('steamshon')") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> I believe implementing `Not` as a logical operator is more general, so below
> is my suggestion.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "NOT (friend_name in ('steamshon'))") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> In this way, we don't need to implement not case for all predicates, such as
> `in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (S2GRAPH-223) Support WhereParser on Vertex.
DOYUNG YOON created S2GRAPH-223:
---
Summary: Support WhereParser on Vertex.
Key: S2GRAPH-223
URL: https://issues.apache.org/jira/browse/S2GRAPH-223
Project: S2Graph
Issue Type: New Feature
Components: s2core
Reporter: DOYUNG YOON
Currently, WhereParser is only available for Edge so it is not possible to
filter vertex with predicates.
One example query would look like followings.
{noformat}
query {
s2graph {
User(id: 1, filter: "name contains 'steamshon'") {
id
}
}
}
{noformat}
I suggest to add vertex support in WhereParser, so GraphQL query can also
benefit from WhereParser.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (S2GRAPH-222) Support Not logical operator in WhereParser.
[
https://issues.apache.org/jira/browse/S2GRAPH-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513258#comment-16513258
]
DOYUNG YOON commented on S2GRAPH-222:
-
[~daewon]
Since my changes are very small, I opened
[https://github.com/apache/incubator-s2graph/pull/174].
Seems like you have feedback on this, and I would appreciate elaborate it.
> Support Not logical operator in WhereParser.
> -
>
> Key: S2GRAPH-222
> URL: https://issues.apache.org/jira/browse/S2GRAPH-222
> Project: S2Graph
> Issue Type: New Feature
> Components: s2core
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
>
> `And/Or` operator is implemented as a logical operator, but `Not` is not
> implemented in WhereParser.
> This is illustrated by following examples.
> Following query works only because we added hardcoded implementation on `not
> in` as predicates.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "friend_name not in ('steamshon')") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> I believe implementing `Not` as a logical operator is more general, so below
> is my suggestion.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "NOT (friend_name in ('steamshon'))") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> In this way, we don't need to implement not case for all predicates, such as
> `in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (S2GRAPH-222) Support Not logical operator in WhereParser.
[
https://issues.apache.org/jira/browse/S2GRAPH-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513257#comment-16513257
]
ASF GitHub Bot commented on S2GRAPH-222:
GitHub user SteamShon opened a pull request:
https://github.com/apache/incubator-s2graph/pull/174
[S2GRAPH-222]: Support Not logical operator in WhereParser.
- add 'NOT' logical operator.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/SteamShon/incubator-s2graph S2GRAPH-222
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-s2graph/pull/174.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #174
commit f288680c46c23ac90fba1741baf494c061921277
Author: DO YUNG YOON
Date: 2018-06-15T02:21:17Z
add Not logical operator on WhereParser.
commit 428c453506d3f89d22135f2518dc2a601f5070f8
Author: DO YUNG YOON
Date: 2018-06-15T02:45:55Z
remove not in.
> Support Not logical operator in WhereParser.
> -
>
> Key: S2GRAPH-222
> URL: https://issues.apache.org/jira/browse/S2GRAPH-222
> Project: S2Graph
> Issue Type: New Feature
> Components: s2core
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
>
> `And/Or` operator is implemented as a logical operator, but `Not` is not
> implemented in WhereParser.
> This is illustrated by following examples.
> Following query works only because we added hardcoded implementation on `not
> in` as predicates.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "friend_name not in ('steamshon')") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> I believe implementing `Not` as a logical operator is more general, so below
> is my suggestion.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "NOT (friend_name in ('steamshon'))") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> In this way, we don't need to implement not case for all predicates, such as
> `in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (S2GRAPH-222) Support Not logical operator in WhereParser.
[
https://issues.apache.org/jira/browse/S2GRAPH-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513243#comment-16513243
]
Daewon Jeong commented on S2GRAPH-222:
--
[~steamshon] I'm interested in the issue.
Is it okay to assign this issue to me?
> Support Not logical operator in WhereParser.
> -
>
> Key: S2GRAPH-222
> URL: https://issues.apache.org/jira/browse/S2GRAPH-222
> Project: S2Graph
> Issue Type: New Feature
> Components: s2core
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
>
> `And/Or` operator is implemented as a logical operator, but `Not` is not
> implemented in WhereParser.
> This is illustrated by following examples.
> Following query works only because we added hardcoded implementation on `not
> in` as predicates.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "friend_name not in ('steamshon')") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> I believe implementing `Not` as a logical operator is more general, so below
> is my suggestion.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "NOT (friend_name in ('steamshon'))") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> In this way, we don't need to implement not case for all predicates, such as
> `in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (S2GRAPH-222) Support Not logical operator in WhereParser.
[
https://issues.apache.org/jira/browse/S2GRAPH-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DOYUNG YOON updated S2GRAPH-222:
Description:
`And/Or` operator is implemented as a logical operator, but `Not` is not
implemented in WhereParser.
This is illustrated by following examples.
Following query works only because we added hardcoded implementation on `not
in` as predicates.
{noformat}
query {
s2graph {
User(id: 1) {
id
Friends(limit: 10, filter: "friend_name not in ('steamshon')") {
User {
id
}
}
}
}
}
{noformat}
I believe implementing `Not` as a logical operator is more general, so below is
my suggestion.
{noformat}
query {
s2graph {
User(id: 1) {
id
Friends(limit: 10, filter: "NOT (friend_name in ('steamshon'))") {
User {
id
}
}
}
}
}
{noformat}
In this way, we don't need to implement not case for all predicates, such as
`in`, `between`, `contains`, `eq`.
was:
`And/Or` operator is implemented as a logical operator, but `Not` is not
implemented in WhereParser.
This is illustrated by following examples.
Following query works only because we added hardcoded implementation on `not
in` as predicates.
{noformat}
query {
s2graph {
User(id: 1) {
id
Friends(limit: 10, filter: "friend_name not in
('steamshon')")
}
}
}
{noformat}
I believe implementing `Not` as a logical operator is more general, so below is
my suggestion.
{noformat}
query {
s2graph {
User(id: 1) {
id
Friends(limit: 10, filter: "NOT (friend_name in
('steamshon'))")
}
}
}
{noformat}
In this way, we don't need to implement not case for all predicates, such as
`in`, `between`, `contains`, `eq`.
> Support Not logical operator in WhereParser.
> -
>
> Key: S2GRAPH-222
> URL: https://issues.apache.org/jira/browse/S2GRAPH-222
> Project: S2Graph
> Issue Type: New Feature
> Components: s2core
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
>
> `And/Or` operator is implemented as a logical operator, but `Not` is not
> implemented in WhereParser.
> This is illustrated by following examples.
> Following query works only because we added hardcoded implementation on `not
> in` as predicates.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "friend_name not in ('steamshon')") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> I believe implementing `Not` as a logical operator is more general, so below
> is my suggestion.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "NOT (friend_name in ('steamshon'))") {
> User {
> id
> }
> }
> }
> }
> }
> {noformat}
> In this way, we don't need to implement not case for all predicates, such as
> `in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (S2GRAPH-222) Support Not logical operator in WhereParser.
[
https://issues.apache.org/jira/browse/S2GRAPH-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
DOYUNG YOON reassigned S2GRAPH-222:
---
Assignee: DOYUNG YOON
> Support Not logical operator in WhereParser.
> -
>
> Key: S2GRAPH-222
> URL: https://issues.apache.org/jira/browse/S2GRAPH-222
> Project: S2Graph
> Issue Type: New Feature
> Components: s2core
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
>
> `And/Or` operator is implemented as a logical operator, but `Not` is not
> implemented in WhereParser.
> This is illustrated by following examples.
> Following query works only because we added hardcoded implementation on `not
> in` as predicates.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "friend_name not in
> ('steamshon')")
> }
> }
> }
> {noformat}
> I believe implementing `Not` as a logical operator is more general, so below
> is my suggestion.
> {noformat}
> query {
> s2graph {
> User(id: 1) {
> id
> Friends(limit: 10, filter: "NOT (friend_name in
> ('steamshon'))")
> }
> }
> }
> {noformat}
> In this way, we don't need to implement not case for all predicates, such as
> `in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (S2GRAPH-222) Support Not logical operator in WhereParser.
DOYUNG YOON created S2GRAPH-222:
---
Summary: Support Not logical operator in WhereParser.
Key: S2GRAPH-222
URL: https://issues.apache.org/jira/browse/S2GRAPH-222
Project: S2Graph
Issue Type: New Feature
Components: s2core
Reporter: DOYUNG YOON
`And/Or` operator is implemented as a logical operator, but `Not` is not
implemented in WhereParser.
This is illustrated by following examples.
Following query works only because we added hardcoded implementation on `not
in` as predicates.
{noformat}
query {
s2graph {
User(id: 1) {
id
Friends(limit: 10, filter: "friend_name not in
('steamshon')")
}
}
}
{noformat}
I believe implementing `Not` as a logical operator is more general, so below is
my suggestion.
{noformat}
query {
s2graph {
User(id: 1) {
id
Friends(limit: 10, filter: "NOT (friend_name in
('steamshon'))")
}
}
}
{noformat}
In this way, we don't need to implement not case for all predicates, such as
`in`, `between`, `contains`, `eq`.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (S2GRAPH-221) Unify configurations for bulk and mutate in S2GraphSink.
[ https://issues.apache.org/jira/browse/S2GRAPH-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16513234#comment-16513234 ] ASF GitHub Bot commented on S2GRAPH-221: GitHub user SteamShon opened a pull request: https://github.com/apache/incubator-s2graph/pull/173 [S2GRAPH-221]: Unify configurations for bulk and mutate in S2GraphSink. - cleanup configurations for S2Graph, S2GraphSink, S2GraphSource. You can merge this pull request into a Git repository by running: $ git pull https://github.com/SteamShon/incubator-s2graph S2GRAPH-221 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/incubator-s2graph/pull/173.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #173 commit e42f7b22f26c7d725f9a33ff6badd7942768e478 Author: DO YUNG YOON Date: 2018-06-14T10:20:51Z initial commit. commit f90a7f54401f67130360ca711a3378a726aeac4b Author: DO YUNG YOON Date: 2018-06-14T20:04:35Z test cases passed. commit da668ace749adf243d43c95413b460bba218731d Author: DO YUNG YOON Date: 2018-06-15T01:09:53Z commit missing changes on s2core. > Unify configurations for bulk and mutate in S2GraphSink. > > > Key: S2GRAPH-221 > URL: https://issues.apache.org/jira/browse/S2GRAPH-221 > Project: S2Graph > Issue Type: Improvement > Components: s2jobs >Reporter: DOYUNG YOON >Assignee: DOYUNG YOON >Priority: Minor > > Currently, S2GraphSink in s2jobs provide two way to sink data from spark into > S2Graph. > 1. mutate: open S2Graph per each executor, then call mutateElements method. > 2. bulk: run spark job to build HFile and run loadIncrementalHFiles. > It is hard to followup options for these two different method, since mutate > options are defined in org.apache.s2graph.spark.sql.streaming.S2SinkConfigs, > and bulkload options are defined in > org.apache.s2graph.s2jobs.load.GraphFileOptions. > I suggest placing all configurations under in one place so it would be easy > to maintain them. > Also, many options for bulk can be removed. > One example is dbUrl options, which is same as "db.default.url" and zkQuorum, > which is same as "hbase.zookeeper.quorum". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (S2GRAPH-203) Support "application/graphql" Content-Type header
[
https://issues.apache.org/jira/browse/S2GRAPH-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512212#comment-16512212
]
ASF GitHub Bot commented on S2GRAPH-203:
GitHub user daewon opened a pull request:
https://github.com/apache/incubator-s2graph/pull/172
[S2GRAPH-203] Support "application/graphql" Content-Type header
I added the ability to allow the GraphQL server to interpret the
`application/graphql` content-type.
no longer need to escape the `graphql query string` to a `json string`
example)
```bash
curl --request POST \
--url http://localhost:8000/graphql \
--header 'content-type: application/graphql' \
--data 'query Welcome {
kakao {
user(id: "daewon") {
id
}
}
}'
```
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/daewon/incubator-s2graph S2GRAPH-203
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-s2graph/pull/172.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #172
commit 23a22775173b1e5d71124fdddcda7c96d8fb4927
Author: daewon
Date: 2018-06-14T09:08:42Z
add content-type: application/graphql
> Support "application/graphql" Content-Type header
> -
>
> Key: S2GRAPH-203
> URL: https://issues.apache.org/jira/browse/S2GRAPH-203
> Project: S2Graph
> Issue Type: Improvement
> Components: s2graphql
>Reporter: Chul Kang
>Assignee: Daewon Jeong
>Priority: Minor
>
> When sending a post request with GraphQL with "application/json"
> Content-Type, it needs to escape GraphQL to string.
> I think if we support the "application/graphql" Conetent-Type, we could use
> GraphQL without escaping.
> http://graphql.org/learn/serving-over-http/#post-request
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (S2GRAPH-220) Filter clause is not working on AnnoyModelFetcher
[
https://issues.apache.org/jira/browse/S2GRAPH-220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16512211#comment-16512211
]
ASF GitHub Bot commented on S2GRAPH-220:
GitHub user SteamShon opened a pull request:
https://github.com/apache/incubator-s2graph/pull/171
[S2GRAPH-220]: Filter clause is not working on AnnoyModelFetcher
- Extract Where and EdgeTransformer to TraversalHelper.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/SteamShon/incubator-s2graph S2GRAPH-220
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-s2graph/pull/171.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #171
commit 3355701f00b34d5e1609e8424d09b50e8211e87a
Author: DO YUNG YOON
Date: 2018-06-14T09:14:22Z
Extract Where and EdgeTransformer to TraversalHelper.
> Filter clause is not working on AnnoyModelFetcher
> -
>
> Key: S2GRAPH-220
> URL: https://issues.apache.org/jira/browse/S2GRAPH-220
> Project: S2Graph
> Issue Type: Bug
> Components: s2core, s2graphql
>Reporter: DOYUNG YOON
>Assignee: DOYUNG YOON
>Priority: Minor
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Below query should filter all edges that have property 'score' smaller than
> 0.1 but current implementation return edges with larger score property value
> than 0.1.
> {noformat}
> {
> s2graph {
> user(id: 0) {
> friends(limit: 10, filter: "score < 0.1") {
> user {
> id
> }
> }
> }
> }
> }
> {noformat}
> After a look through the current master, I found out Where parser and
> EdgeTransformer are processed on AsynchbaseEdgeFetcher and RocksEdgeFetcher
> by calling StorageIO.toEdges method, but this is missing on AnnoyModelFetcher.
> I suggest to extract `Where` and `EdgeTransformer` from StorageIO.toEdges to
> helper so other Fetcher implementation can easily use this helper to apply
> them correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (S2GRAPH-221) Unify configurations for bulk and mutate in S2GraphSink.
[ https://issues.apache.org/jira/browse/S2GRAPH-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] DOYUNG YOON reassigned S2GRAPH-221: --- Assignee: DOYUNG YOON > Unify configurations for bulk and mutate in S2GraphSink. > > > Key: S2GRAPH-221 > URL: https://issues.apache.org/jira/browse/S2GRAPH-221 > Project: S2Graph > Issue Type: Improvement > Components: s2jobs >Reporter: DOYUNG YOON >Assignee: DOYUNG YOON >Priority: Minor > > Currently, S2GraphSink in s2jobs provide two way to sink data from spark into > S2Graph. > 1. mutate: open S2Graph per each executor, then call mutateElements method. > 2. bulk: run spark job to build HFile and run loadIncrementalHFiles. > It is hard to followup options for these two different method, since mutate > options are defined in org.apache.s2graph.spark.sql.streaming.S2SinkConfigs, > and bulkload options are defined in > org.apache.s2graph.s2jobs.load.GraphFileOptions. > I suggest placing all configurations under in one place so it would be easy > to maintain them. > Also, many options for bulk can be removed. > One example is dbUrl options, which is same as "db.default.url" and zkQuorum, > which is same as "hbase.zookeeper.quorum". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (S2GRAPH-221) Unify configurations for bulk and mutate in S2GraphSink.
DOYUNG YOON created S2GRAPH-221: --- Summary: Unify configurations for bulk and mutate in S2GraphSink. Key: S2GRAPH-221 URL: https://issues.apache.org/jira/browse/S2GRAPH-221 Project: S2Graph Issue Type: Improvement Components: s2jobs Reporter: DOYUNG YOON Currently, S2GraphSink in s2jobs provide two way to sink data from spark into S2Graph. 1. mutate: open S2Graph per each executor, then call mutateElements method. 2. bulk: run spark job to build HFile and run loadIncrementalHFiles. It is hard to followup options for these two different method, since mutate options are defined in org.apache.s2graph.spark.sql.streaming.S2SinkConfigs, and bulkload options are defined in org.apache.s2graph.s2jobs.load.GraphFileOptions. I suggest placing all configurations under in one place so it would be easy to maintain them. Also, many options for bulk can be removed. One example is dbUrl options, which is same as "db.default.url" and zkQuorum, which is same as "hbase.zookeeper.quorum". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
