Date   

Re: [DISCUSS] Splitting janusgraph-cassandra

Samant Maharaj <samant...@...>
 

I'm now working on bringing the branch up to date against master and will raise the PR as soon as it's ready.

There've been a few changes since I did that initial work so it might take a short while to get it all squared away.

Regards,
Samant 


On Friday, 30 June 2017 14:38:03 UTC+12, sjudeng wrote:
Samant, It's been 5 days and no one has yelled too loud so I think it's reasonable to move forward with your PR on this if you're still up for it.

Ted, I don't think the reorganization here would cause any additional complexities with the eventual deprecation of Thrift. On the surface it seems to me it might make it simpler to carry out the deprecation/removal if the Thrift components are separated into a standalone module like here.

On Friday, June 23, 2017 at 10:45:50 PM UTC-5, sjudeng wrote:
All,

Samant has said he should be able to continue working on this effort. The current proposal is to refactor into the following structure.

├─ janusgraph-cassandra-parent/
│   ├── astyanax
│   ├── cql
│   ├── core
│   ├── embedded
│   ├── test
│   ├── thrift

+1 for me. I think it's a step in the right direction and I'd hate to see the work already done on this go to waste.

Jason, is this something that needs a separate vote thread or can the work/PR just move forward?

Samant, What do you think about Ted's question above?


On Saturday, June 17, 2017 at 12:28:41 PM UTC-5, sjudeng wrote:
Hi Samant,

Are you still able to move forward with getting your work on this submitted? If so do you want to call a vote on the proposed refactoring or do you want me to? One way or another I think the refactoring is definitely needed. It came up in a recent PR where configuration needed to be duplicated in janusgraph-cassandra and janusgraph-cql because of the current state of things.

Thanks!


Re: Guided use of Lombok in JG?

Alexander Patrikalakis <amcpatr...@...>
 

To help spark discussion, I have proposed a use of Lombok here:
https://github.com/JanusGraph/janusgraph/pull/386

It reduces the janusgraph-core code base by 2327 lines.


On Tuesday, June 13, 2017 at 4:15:53 PM UTC+8, Samik R wrote:
My thought exactly - oh well!!
Regards.
-Samik

On 07-Jun-17 6:31 AM, Terry Moschou wrote:
Too bad JanusGraph wasn't written in Scala - boilerplate is kinda Java's thing right haha ;-p



Re: Not able to 'addEdge' to 'CacheVertex'

Robert Dale <rob...@...>
 

One problem is that you are mixing APIs.  There is a direction in TinkerPop to even further separate the lines between user Traversal API and implementer Graph API. So it is highly recommend to stick with the user Traversal API.  Here is the equivalent gremlin:   

gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]

// starting with an empty graph
gremlin
> g.V()
gremlin
> g.E()

// get or create all vertexes and edges
gremlin
> g.inject(1).coalesce(
             __
.V().has('person','name','marko'),
             __
.addV('person').property('name','marko')).as('marko').
           coalesce
(
             __
.V().has('person','name','stephen'),
             __
.addV('person').property('name','stephen')).as('stephen').
           coalesce
(
             __
.in('knows').has('person','name','marko'),
             __
.addE('knows').from('marko'))
==>e[4][0-knows->2]

// show the path that now exists
gremlin
> g.V().outE().inV().path().by(valueMap(true))
==>[[name:[marko],label:person,id:0],[label:knows,id:4],[name:[stephen],label:person,id:2]]

// run it again, nothing new should be created
gremlin
> g.inject(1).coalesce(__.V().has('person','name','marko'),__.addV('person').property('name','marko')).as('marko').coalesce(__.V().has('person','name','stephen'),__.addV('person').property('name','stephen')).as('stephen').coalesce(__.in('knows').has('person','name','marko'),__.addE('knows').from('marko'))
==>v[0]

// show that only the previous relations exist, nothing new
gremlin
> g.V().outE().inV().path().by(valueMap(true))
==>[[name:[marko],label:person,id:0],[label:knows,id:4],[name:[stephen],label:person,id:2]]



-- 
Robert Dale


On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Re: 0.2.0-SNAPSHOT updates?

Austin Sharp <austins...@...>
 

FWIW we're very eager to see new snapshots and hopefully an 0.2.0 release soon as well. Eager enough that we are working on a branch that works with the 0.2.0 snapshot, and debating whether we'd (if it takes too long) release with the 0.2.0 snapshot or backport some changes to a forked version of 0.1.1.


On Tuesday, June 27, 2017 at 9:08:54 AM UTC-7, Ted Wilmes wrote:
Hey Jason,
I think you should be good to go since you added your name to the list on this issue: https://github.com/janusgraph/janusgraph/issues/97. With Sonatype permissions you'll be able to deploy the snapshot. Since that doesn't include binaries at this point, I've used the GitHub release feature to upload snapshot binaries before.  If you try it out and run into any issues, let me know.

--Ted

On Monday, June 26, 2017 at 8:42:20 PM UTC-5, Jason Plurad wrote:
Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason

On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
Hello,

I've been waiting for some features recently added to Janus to give it a go.
But it seems that last snapshot available for 0.2.0 release is a month old (24 May 2017):

https://oss.sonatype.org/content/repositories/snapshots/org/janusgraph/janusgraph-core/0.2.0-SNAPSHOT/

I know I could built it from source and host it somewhere privately, but I kind of defeats the purpose of having dev snapshots in the first place.

Can we expect some updates to this snapshot anytime soon?

Having this automated and pushed on regular basis would be great too :)


Re: Not able to 'addEdge' to 'CacheVertex'

David Pitera <piter...@...>
 

So I am not sure this will fix your problem, but please give it a try and let me know if it does:

When you instantiate a JanusGraph, [this transaction](https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/graphdb/tinkerpop/JanusGraphBlueprintsGraph.java#L57) is opened for you. Rather than calling `JanusGraphTransaction tx = graph.newTransaction();`, why don't you emit that line and end your vertex/edge mutation code with `graph.tx().commit();`

I wonder if you have open, non-committed transactions running around; you can use [this method](https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/graphdb/database/StandardJanusGraph.java#L306) to explore that possibility.

On Fri, Jun 30, 2017 at 12:43 AM, Teena K <avidlea...@...> wrote:
    
    JanusGraph graph = JanusGraphFactory.open("<path>/janusgraph/conf/janusgraph-cassandra.properties");
    JanusGraphTransaction tx = graph.newTransaction();    
    GraphTraversalSource g = graph.traversal();

    <code to add vertices and edges>

    tx.commit();

    The transaction is committed after all the code is executed.

On Thursday, June 29, 2017 at 10:04:20 PM UTC+5:30, Jason Plurad wrote:
You've left out some context here. How are g` and `tx` initialized? Where is the transaction committed?

On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] Splitting janusgraph-cassandra

Ted Wilmes <twi...@...>
 

Yeah, seems like it would be easier to tease apart the pieces we wanted to deprecate after this restructure so I think it makes good sense.

--Ted

On Thu, Jun 29, 2017 at 9:38 PM, sjudeng <sju...@...> wrote:
Samant, It's been 5 days and no one has yelled too loud so I think it's reasonable to move forward with your PR on this if you're still up for it.

Ted, I don't think the reorganization here would cause any additional complexities with the eventual deprecation of Thrift. On the surface it seems to me it might make it simpler to carry out the deprecation/removal if the Thrift components are separated into a standalone module like here.


On Friday, June 23, 2017 at 10:45:50 PM UTC-5, sjudeng wrote:
All,

Samant has said he should be able to continue working on this effort. The current proposal is to refactor into the following structure.

├─ janusgraph-cassandra-parent/
│   ├── astyanax
│   ├── cql
│   ├── core
│   ├── embedded
│   ├── test
│   ├── thrift

+1 for me. I think it's a step in the right direction and I'd hate to see the work already done on this go to waste.

Jason, is this something that needs a separate vote thread or can the work/PR just move forward?

Samant, What do you think about Ted's question above?


On Saturday, June 17, 2017 at 12:28:41 PM UTC-5, sjudeng wrote:
Hi Samant,

Are you still able to move forward with getting your work on this submitted? If so do you want to call a vote on the proposed refactoring or do you want me to? One way or another I think the refactoring is definitely needed. It came up in a recent PR where configuration needed to be duplicated in janusgraph-cassandra and janusgraph-cql because of the current state of things.

Thanks!

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developer list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/01ft3Fcoht4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Potential breaking changes in 0.2.0

david.c...@...
 

Yes I will add a logic to the getIndexStoreName() and also when JanusGraph query elasticsearch.

For the index delation work, if the index is not split, I can do it but it can take a long long time : it's depending of the number of document.

Le vendredi 30 juin 2017 04:31:27 UTC+2, sjudeng a écrit :
Although it's not as clean I think it's worth pursing the configuration option. You could call it something obtrusive like "index.elasicsearch.use-deprecated-multitype-index". If possible I think we'd want it to default to false so all new indices are split, but be treated as true if not present as in the case for legacy indices. As far as implementation complexity, would it maybe be as simple as adding logic to your ElasticSearchIndex.getIndexStoreName() method? Regarding your desired index deletion work, could you move forward if support is limited to single-type indices (e.g. so there'd be an additional conditional at https://github.com/JanusGraph/janusgraph/blob/bfa3c970555932d4983155168322f72297aaee85/janusgraph-core/src/main/java/org/janusgraph/graphdb/olap/job/IndexRemoveJob.java#L104)?

I'd still like to hear from others as well but this is what I'm thinking.

On Wednesday, June 28, 2017 at 11:47:49 AM UTC-5, Davide Bolcioni wrote:
I would expect an incompatible change to bump the major version, so 1.*

On Wed, Jun 28, 2017 at 9:00 AM, david.clement90 via JanusGraph developer list <jan...@...> wrote:
I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
There is no place like /home.


Re: Not able to 'addEdge' to 'CacheVertex'

Teena K <avidlea...@...>
 

    
    JanusGraph graph = JanusGraphFactory.open("<path>/janusgraph/conf/janusgraph-cassandra.properties");
    JanusGraphTransaction tx = graph.newTransaction();    
    GraphTraversalSource g = graph.traversal();

    <code to add vertices and edges>

    tx.commit();

    The transaction is committed after all the code is executed.


On Thursday, June 29, 2017 at 10:04:20 PM UTC+5:30, Jason Plurad wrote:
You've left out some context here. How are g` and `tx` initialized? Where is the transaction committed?

On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Re: [DISCUSS] Splitting janusgraph-cassandra

sjudeng <sju...@...>
 

Samant, It's been 5 days and no one has yelled too loud so I think it's reasonable to move forward with your PR on this if you're still up for it.

Ted, I don't think the reorganization here would cause any additional complexities with the eventual deprecation of Thrift. On the surface it seems to me it might make it simpler to carry out the deprecation/removal if the Thrift components are separated into a standalone module like here.


On Friday, June 23, 2017 at 10:45:50 PM UTC-5, sjudeng wrote:
All,

Samant has said he should be able to continue working on this effort. The current proposal is to refactor into the following structure.

├─ janusgraph-cassandra-parent/
│   ├── astyanax
│   ├── cql
│   ├── core
│   ├── embedded
│   ├── test
│   ├── thrift

+1 for me. I think it's a step in the right direction and I'd hate to see the work already done on this go to waste.

Jason, is this something that needs a separate vote thread or can the work/PR just move forward?

Samant, What do you think about Ted's question above?


On Saturday, June 17, 2017 at 12:28:41 PM UTC-5, sjudeng wrote:
Hi Samant,

Are you still able to move forward with getting your work on this submitted? If so do you want to call a vote on the proposed refactoring or do you want me to? One way or another I think the refactoring is definitely needed. It came up in a recent PR where configuration needed to be duplicated in janusgraph-cassandra and janusgraph-cql because of the current state of things.

Thanks!


Re: Potential breaking changes in 0.2.0

sjudeng <sju...@...>
 

Although it's not as clean I think it's worth pursing the configuration option. You could call it something obtrusive like "index.elasicsearch.use-deprecated-multitype-index". If possible I think we'd want it to default to false so all new indices are split, but be treated as true if not present as in the case for legacy indices. As far as implementation complexity, would it maybe be as simple as adding logic to your ElasticSearchIndex.getIndexStoreName() method? Regarding your desired index deletion work, could you move forward if support is limited to single-type indices (e.g. so there'd be an additional conditional at https://github.com/JanusGraph/janusgraph/blob/bfa3c970555932d4983155168322f72297aaee85/janusgraph-core/src/main/java/org/janusgraph/graphdb/olap/job/IndexRemoveJob.java#L104)?

I'd still like to hear from others as well but this is what I'm thinking.


On Wednesday, June 28, 2017 at 11:47:49 AM UTC-5, Davide Bolcioni wrote:
I would expect an incompatible change to bump the major version, so 1.*

On Wed, Jun 28, 2017 at 9:00 AM, david.clement90 via JanusGraph developer list <janusgr...@googlegroups.com> wrote:
I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
There is no place like /home.


Re: Not able to 'addEdge' to 'CacheVertex'

Jason Plurad <plu...@...>
 

You've left out some context here. How are g` and `tx` initialized? Where is the transaction committed?

On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Not able to 'addEdge' to 'CacheVertex'

Teena K <avidlea...@...>
 


I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Re: Potential breaking changes in 0.2.0

Davide Bolcioni <dbol...@...>
 

I would expect an incompatible change to bump the major version, so 1.*

On Wed, Jun 28, 2017 at 9:00 AM, david.clement90 via JanusGraph developer list <janusgr...@...> wrote:
I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
There is no place like /home.


Potential breaking changes in 0.2.0

david.c...@...
 

I add this thread to discuss about breaking change in 0.2.0 with this PR https://github.com/JanusGraph/janusgraph/pull/336.

This PR add a breaking change for Elasticsearch backend because it Elasticsearch split index into N indexes.
To deals with this, we have three options :
  1.  0.2.0 is not compatible with 0.1.x
  2. We create a script to migrate index.
  3. We make the configuration switch.
Between 2 and 3, I prefer 2 because I would like to add a delete method by index to solve https://github.com/JanusGraph/janusgraph/issues/354 and to remove this https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/graphdb/olap/job/IndexRemoveJob.java#L105

But, for me 0.2.0 is already not compatible with 0.1.x because Geoshape serialization (https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-core/src/main/java/org/janusgraph/core/attribute/Geoshape.java#L542).
In 0.1.x Geoshape serialization was en tab of float, in 0.2.0 JanusGraph use JtsBinaryCodec. So a geoshape serializes in 0.1.x can not be read by 0.2.0. 

What do you think ?

I did not know if there are any other breaking change.

David


Re: 0.2.0-SNAPSHOT updates?

Ted Wilmes <twi...@...>
 

Hey Jason,
I think you should be good to go since you added your name to the list on this issue: https://github.com/janusgraph/janusgraph/issues/97. With Sonatype permissions you'll be able to deploy the snapshot. Since that doesn't include binaries at this point, I've used the GitHub release feature to upload snapshot binaries before.  If you try it out and run into any issues, let me know.

--Ted

On Monday, June 26, 2017 at 8:42:20 PM UTC-5, Jason Plurad wrote:
Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason

On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
Hello,

I've been waiting for some features recently added to Janus to give it a go.
But it seems that last snapshot available for 0.2.0 release is a month old (24 May 2017):

https://oss.sonatype.org/content/repositories/snapshots/org/janusgraph/janusgraph-core/0.2.0-SNAPSHOT/

I know I could built it from source and host it somewhere privately, but I kind of defeats the purpose of having dev snapshots in the first place.

Can we expect some updates to this snapshot anytime soon?

Having this automated and pushed on regular basis would be great too :)


Re: 0.2.0-SNAPSHOT updates?

Jason Plurad <plu...@...>
 

Thanks, Ted. Are there other committers that have authority to publish a snapshot? I'd be happy to be added to the list of publishers if we had a writeup on how to do it.

-- Jason


On Friday, June 23, 2017 at 12:38:58 PM UTC-4, Ted Wilmes wrote:
Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted

On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, wojcik.w wrote:
Hello,

I've been waiting for some features recently added to Janus to give it a go.
But it seems that last snapshot available for 0.2.0 release is a month old (24 May 2017):

https://oss.sonatype.org/content/repositories/snapshots/org/janusgraph/janusgraph-core/0.2.0-SNAPSHOT/

I know I could built it from source and host it somewhere privately, but I kind of defeats the purpose of having dev snapshots in the first place.

Can we expect some updates to this snapshot anytime soon?

Having this automated and pushed on regular basis would be great too :)


Re: [DISCUSS] Splitting janusgraph-cassandra

sjudeng <sju...@...>
 

All,

Samant has said he should be able to continue working on this effort. The current proposal is to refactor into the following structure.

├─ janusgraph-cassandra-parent/
│   ├── astyanax
│   ├── cql
│   ├── core
│   ├── embedded
│   ├── test
│   ├── thrift

+1 for me. I think it's a step in the right direction and I'd hate to see the work already done on this go to waste.

Jason, is this something that needs a separate vote thread or can the work/PR just move forward?

Samant, What do you think about Ted's question above?


On Saturday, June 17, 2017 at 12:28:41 PM UTC-5, sjudeng wrote:
Hi Samant,

Are you still able to move forward with getting your work on this submitted? If so do you want to call a vote on the proposed refactoring or do you want me to? One way or another I think the refactoring is definitely needed. It came up in a recent PR where configuration needed to be duplicated in janusgraph-cassandra and janusgraph-cql because of the current state of things.

Thanks!


Re: 0.2.0-SNAPSHOT updates?

Ted Wilmes <twi...@...>
 

Hello,
We'll probably start working on a release candidate for 0.2.0 shortly so I'll get another snapshot published before that, and yes, agreed on the automation! That's something that we need to get in place.

--Ted


On Thursday, June 22, 2017 at 8:10:09 AM UTC-5, woj...@... wrote:
Hello,

I've been waiting for some features recently added to Janus to give it a go.
But it seems that last snapshot available for 0.2.0 release is a month old (24 May 2017):

https://oss.sonatype.org/content/repositories/snapshots/org/janusgraph/janusgraph-core/0.2.0-SNAPSHOT/

I know I could built it from source and host it somewhere privately, but I kind of defeats the purpose of having dev snapshots in the first place.

Can we expect some updates to this snapshot anytime soon?

Having this automated and pushed on regular basis would be great too :)


Re: [VOTE] Elasticsearch upgrade

spirit...@...
 

+1

在 2017年3月10日星期五 UTC+8上午1:13:59,sjudeng写道:

I'd like to request a vote on the following proposal for proceeding with updates to Elasticsearch in JanusGraph (see this discuss thread for more information):

  1. Update to support ES 2.x and 5.x with native ES REST client. This work is complete and available for review in #79.
  2. Update to remove transport client and replace native ES REST client with the Jest high level ES HTTP client. This work is in progress and being tracked in #160.


Re: Compiling locally with gremlin-core 3.3.0-SNAPSHOT

sjudeng <sju...@...>
 

Hi Kedar,

I posted my full test procedure: https://gist.github.com/sjudeng/093687d5f435ddbf46ea1808fbc4b398

At the bottom of that page under "test OLAP traversal" there's the read-hbase.properties file (copied from read-cassandra.properties) that was used. Also note the common Spark configuration from the setup section that was also included in the file.

On Wednesday, June 21, 2017 at 11:43:46 PM UTC-5, Kedar Mhaswade wrote:
Hi Sjudeng,

Ah, I missed that one. Now I am able to run SGC, but I am still seeing issues with class loading [1]. Am I to copy some jar files from somewhere to the lib-folder of JG workspace (local clone)?

Is it possible for you to share with me the properties file with which you initialize the graph?
My config file is [2].

Thanks,
Kedar

[1]

Caused by: java.lang.ClassNotFoundException: org.apache.spark.deploy.yarn.YarnSparkHadoopUtil

at java.net.URLClassLoader.findClass(URLClassLoader.java:381)

at java.lang.ClassLoader.loadClass(ClassLoader.java:424)

at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)

at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

at java.lang.Class.forName0(Native Method)

at java.lang.Class.forName(Class.java:348)

at org.apache.spark.util.Utils$.classForName(Utils.scala:228)

at org.apache.spark.deploy.SparkHadoopUtil$.liftedTree1$1(SparkHadoopUtil.scala:413)

[2]

#

# Hadoop Graph Configuration

#

gremlin.graph=org.apache.tinkerpop.gremlin.hadoop.structure.HadoopGraph

# with my changes

gremlin.hadoop.graphInputFormat=org.janusgraph.hadoop.formats.cassandra.Cassandra3InputFormat

gremlin.hadoop.graphOutputFormat=org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoOutputFormat


gremlin.hadoop.jarsInDistributedCache=true

gremlin.hadoop.inputLocation=none

gremlin.hadoop.outputLocation=output


#

# JanusGraph Cassandra InputFormat configuration

#

janusgraphmr.ioformat.conf.storage.backend=cassandrathrift

janusgraphmr.ioformat.conf.storage.hostname=<ip1, ip2...>

janusgraphmr.ioformat.conf.storage.port=9160

janusgraphmr.ioformat.conf.storage.cassandra.keyspace=janusgraph

# more config

# default for timeout: 10000 ms = 10 s

janusgraphmr.ioformat.conf.storage.connection-timeout=100000 


#

# Apache Cassandra InputFormat configuration

#

cassandra.input.partitioner.class=org.apache.cassandra.dht.Murmur3Partitioner


#

# SparkGraphComputer Configuration

#

spark.master=yarn

spark.serializer=org.apache.spark.serializer.KryoSerializer

spark.executor.instances=100


# from vtslab on GH

spark.app.name=uGraph

spark.ui.port=4050

spark.executor.memory=2g

spark.executorEnv.SPARK_CONF_DIR=/etc/spark/conf

spark.executorEnv.HADOOP_CONF_DIR=/etc/hadoop/conf



On Wed, Jun 21, 2017 at 3:05 PM, sjudeng <s...@...> wrote:
Hi Kedar,

I think you just need to load the spark plugin.

gremlin> :plugin use tinkerpop.spark

On Wednesday, June 21, 2017 at 3:26:15 PM UTC-5, Kedar Mhaswade wrote:
Hi sjudeng,

Is this update missing SparkGraphComputer? After building tp33 branch, I get the following on gremlin console:

gremlin> graph1 = GraphFactory.open('conf/hadoop-graph/read-cassandra.properties')

==>hadoopgraph[cassandrainputformat->gryooutputformat]

gremlin> olap = graph1.traversal().withComputer(SparkGraphComputer)

No such property: SparkGraphComputer for class: groovysh_evaluate

What am I missing? How were you able to run the queries with Spark/Yarn?


Regards,

Kedar


On Wed, Jun 21, 2017 at 10:01 AM, Kedar Mhaswade <k...@...> wrote:


On Wed, Jun 21, 2017 at 4:01 AM, sjudeng <s...@...> wrote:
In case there's interest the branch in https://github.com/sjudeng/janusgraph/tree/tp33 has some very early work on building JanusGraph with TinkerPop 3.3.0-SNAPSHOT. At this point it's compiling and I've tested OLAP traversals and BulkLoaderVertexProgram without issue using Spark 2.1 on Yarn (Cloudera) with some small test graphs in HBase. Currently only in memory TinkerPop unit test suites have been run and there are a handful of failures related to profiling, graph I/O involving geometries and graph computer. The couple graph computer test failures may just be issues with FulgoraGraphComputer (e.g. not something more general that might affect SparkGraphComputer) but I'm not sure yet. I'll be pushing more commits and likely squashing/rebasing along the way so keep that in mind if pulling.

Thanks sjudeng!

I will take a look at the changes and try out some graphs against a Cassandra-3 backend (which means it will need my PR). Is there any chance that this will become a part of JanusGraph 0.2.0 release?

Regards,
Kedar
 

--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "JanusGraph developer list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgraph-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

1281 - 1300 of 1585