Date   

Re: [VOTE] JanusGraph 0.1.1 Release

Misha Brukman <mbru...@...>
 

+1

On Thu, May 11, 2017 at 11:42 AM, Ted Wilmes <twi...@...> wrote:
Hello,

We are happy to announce that JanusGraph 0.1.1 is ready for release.

The release artifacts can be found at this location:
        
A binary distribution is provided for user convenience:

The GPG key used to sign the release artifacts is available at:

The docs can be found here:

The release tag in Git can be found here:

The release notes are available here:

This [VOTE] will open for the next 72 hours --- closing Sunday (5/14/2017) at 11:00 AM CST.

My vote is +1.

Thank you very much,
Ted Wilmes

--
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.


[VOTE] JanusGraph 0.1.1 Release

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

Hello,

We are happy to announce that JanusGraph 0.1.1 is ready for release.

The release artifacts can be found at this location:
        
A binary distribution is provided for user convenience:

The GPG key used to sign the release artifacts is available at:

The docs can be found here:

The release tag in Git can be found here:

The release notes are available here:

This [VOTE] will open for the next 72 hours --- closing Sunday (5/14/2017) at 11:00 AM CST.

My vote is +1.

Thank you very much,
Ted Wilmes


Re: [DISCUSS] 0.1.1 point fix release

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

Thanks Sjudeng, that's exactly what I was running into. I just put a PR[1] in with the release prep, artifacts are built and staged, so close to ready for a vote. After I get a review, I can merge this and create the pre-release on github for vote.

https://github.com/JanusGraph/janusgraph/pull/269

Thanks,
Ted


On Wednesday, May 10, 2017 at 9:25:28 PM UTC-5, sjudeng wrote:
FYI I had seen sporadic Solr errors ("Not enough nodes to handle the request") before as well in some testing environments, in particular in Travis. In digging into this as part of #251 (Travis build improvements) I found the issue was a bug in the detection logic around live recoveries in SolrIndex. The issue is fixed in that PR branch, though that doesn't help for this release. In the meantime I've found testing under CentOS 7 to be stable regarding these errors.


Re: [DISCUSS] 0.1.1 point fix release

sjudeng <sju...@...>
 

FYI I had seen sporadic Solr errors ("Not enough nodes to handle the request") before as well in some testing environments, in particular in Travis. In digging into this as part of #251 (Travis build improvements) I found the issue was a bug in the detection logic around live recoveries in SolrIndex. The issue is fixed in that PR branch, though that doesn't help for this release. In the meantime I've found testing under CentOS 7 to be stable regarding these errors.


Re: [DISCUSS] 0.1.1 point fix release

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

I was delayed but I'm finishing up the testing. I was getting a few spurious Solr failures so I'm completing some re-runs now. I'll work on getting things bundled up after this if all is good and then start the vote.

Thanks,
Ted 


On Friday, May 5, 2017 at 8:38:45 AM UTC-5, Ted Wilmes wrote:
Sounds like folks are in agreement. I'll run the TinkerPop tests, etc. on 0.1.1-SNAPSHOT and put together a RC and shoot for starting vote sometime Monday unless there are any objections in the meantime.

--Ted

On Wednesday, May 3, 2017 at 5:44:26 PM UTC-5, Rafael Fernandes wrote:
+1


Re: [DISCUSS] 0.1.1 point fix release

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

Sounds like folks are in agreement. I'll run the TinkerPop tests, etc. on 0.1.1-SNAPSHOT and put together a RC and shoot for starting vote sometime Monday unless there are any objections in the meantime.

--Ted


On Wednesday, May 3, 2017 at 5:44:26 PM UTC-5, Rafael Fernandes wrote:
+1


Re: JanusGraph and Cassandra-3 (issue 172)

Kedar Mhaswade <ke...@...>
 

Thanks Ted.

Going ahead, I will use the report page (https://github.com/JanusGraph/janusgraph/issues/172) to post updates etc. Will resort to this thread if I am stuck and I am sure you guys will help me out!

Regards,
Kedar

On Wed, May 3, 2017 at 4:10 PM, Ted Wilmes <twi...@...> wrote:
That sounds like a good plan to me Kedar. Thanks for the detailed response. Your point on not basing off that other branch makes good sense to me. For some reason, I was thinking (incorrectly) that the CassandraBinaryRecordReader lived in the Cassandra module, which it does not. Looking forward to testing this out!

Thanks,
Ted

On Wed, May 3, 2017 at 4:24 PM, Kedar Mhaswade <ke...@...> wrote:
Hi Ted,

Thanks for your encouragement. Some responses inline.


On Wed, May 3, 2017 at 9:51 AM, Ted Wilmes <twi...@...> wrote:
Hi Kedar,
Thanks for bringing this discussion over to the dev list. I think it'll benefit from the wider audience. If I read things correctly, I think that CqlRecordReader is available in 2.1 [1].

Correct. This comes via the cassandra-all-2.1.9 dependency that JanusGraph right now has. 
 
Perhaps we could see if it'll work against Cassandra 3?

It's the path that we are inclined toward taking. In Cassandra 2.x, there was a class CassandraServer which had methods like execute_cql_query, execute_cql3_query and so on that used to handle the CQL queries (CassandraServer was in a package named erroneously as org.apache.cassandra.thrift, a thift subpackage class handling CQL queries!  -- looking at you, Cassandra devs). In Cassandra 3.x, CassandraServer class is gone, but hopefully the actual CQL queries would be handled in a backward compatible manner by its reincarnation. 

That way, all the unit tests etc. will continue to run against the embedded Cassandra-2.x and in real life JG can speak with Cassandra-3.x at least for analytic queries (issued via the janusgraph-hadoop-parent/org.janusgraph.hadoop.formats.cassandra package). 

Thus, if CQL server implementation inside of Cassandra-3.x is backward compatible with the Cassandra-2.1.9 client used by hadoop classes in JanusGraph, we should be (barely) covered ;). This also lets JanusGraph not require Cassandra-3.x.

To be a little more concrete, I am planning to take a shot at reimplementing the logic in org.janusgraph.hadoop.formats.cassandra.CassandraBinaryRecordReader and org.janusgraph.hadoop.formats.cassandra.CassandraBinaryInputFormat by wrapping the org.apache.cassandra.hadoop.cql3.CqlRecordReader instead of org.apache.cassandra.hadoop.ColumnFamilyRecordReader (A Cassandra-2.x class which really is the problem because that embodies the incompatible schema change and of course is gone in Cassandra-3.x -- see my email to Cassandra devs). We hope that this change is going to be fairly localized.

Another data point is that org.apache.cassandra.hadoop.cql3.CqlRecordReader is part of Cassandra 3.x which means if we were to upgrade JG to use Cassandra-3.x, we'll be in good shape.

If anyone on the list is knowledgeable (LaRocque, Broecheler from git log) about this, please let me know if this approach will work.


Looking at the commit history since then, there are a number of additions but at its heart, it looks like that code is using the Datastax Cassandra driver to communicate with the cluster. The other JanusGraph CQL PR that is in-flight [2] brings this driver in at version 3.1.4. Looking at the compatibility table, that should be compatible with Cassandra 3.0+[3]. What would you think about basing your work off of that branch to see if you can get something up and running?

We have been looking at that contribution, but we feel like that it is more geared toward the OLTP like queries and it is yet another variable into an already high combinatoric complexity of dependencies. So, for now, we'll not rely on cql-backend branch changes.


Bumping the Janus dependency to 3.0 may be necessary, but that would most likely cause problems for folks who were running Cassandra in embedded mode. I'm not sure if anyone does that (ie. connecting using the C* apis vs. thrift, astyanax drivers with Janus & Cassandra in the same JVM), but if you do, speak up! I think for the moment it would be good to see if we could get this working without the version bump.

If the plan above works, then we just may have the best of both the worlds, because the embedded Cassandra-2.x will continue to work.

Makes sense?

Regards,
Kedar
 

Thanks for all the work on this,
Ted

[3] https://docs.datastax.com/en/developer/driver-matrix/doc/javaDrivers.html


On Wednesday, May 3, 2017 at 8:34:51 AM UTC-5, Kedar Mhaswade wrote:
Hello all,

See Issue-172 whose synopsis is: CassandraBinaryRecordReader not compatible with Cassandra 3.0+. There are a few comments and several useful links on the bug report that I have been discussing with Ted Wilmes. I have also asked Cassandra developers for advice.

It appears to me that we'll have to make JanusGraph require Cassandra-3 because of this issue. 

Thoughts, comments?

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-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.




Re: JanusGraph and Cassandra-3 (issue 172)

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

That sounds like a good plan to me Kedar. Thanks for the detailed response. Your point on not basing off that other branch makes good sense to me. For some reason, I was thinking (incorrectly) that the CassandraBinaryRecordReader lived in the Cassandra module, which it does not. Looking forward to testing this out!

Thanks,
Ted

On Wed, May 3, 2017 at 4:24 PM, Kedar Mhaswade <ke...@...> wrote:
Hi Ted,

Thanks for your encouragement. Some responses inline.


On Wed, May 3, 2017 at 9:51 AM, Ted Wilmes <twi...@...> wrote:
Hi Kedar,
Thanks for bringing this discussion over to the dev list. I think it'll benefit from the wider audience. If I read things correctly, I think that CqlRecordReader is available in 2.1 [1].

Correct. This comes via the cassandra-all-2.1.9 dependency that JanusGraph right now has. 
 
Perhaps we could see if it'll work against Cassandra 3?

It's the path that we are inclined toward taking. In Cassandra 2.x, there was a class CassandraServer which had methods like execute_cql_query, execute_cql3_query and so on that used to handle the CQL queries (CassandraServer was in a package named erroneously as org.apache.cassandra.thrift, a thift subpackage class handling CQL queries!  -- looking at you, Cassandra devs). In Cassandra 3.x, CassandraServer class is gone, but hopefully the actual CQL queries would be handled in a backward compatible manner by its reincarnation. 

That way, all the unit tests etc. will continue to run against the embedded Cassandra-2.x and in real life JG can speak with Cassandra-3.x at least for analytic queries (issued via the janusgraph-hadoop-parent/org.janusgraph.hadoop.formats.cassandra package). 

Thus, if CQL server implementation inside of Cassandra-3.x is backward compatible with the Cassandra-2.1.9 client used by hadoop classes in JanusGraph, we should be (barely) covered ;). This also lets JanusGraph not require Cassandra-3.x.

To be a little more concrete, I am planning to take a shot at reimplementing the logic in org.janusgraph.hadoop.formats.cassandra.CassandraBinaryRecordReader and org.janusgraph.hadoop.formats.cassandra.CassandraBinaryInputFormat by wrapping the org.apache.cassandra.hadoop.cql3.CqlRecordReader instead of org.apache.cassandra.hadoop.ColumnFamilyRecordReader (A Cassandra-2.x class which really is the problem because that embodies the incompatible schema change and of course is gone in Cassandra-3.x -- see my email to Cassandra devs). We hope that this change is going to be fairly localized.

Another data point is that org.apache.cassandra.hadoop.cql3.CqlRecordReader is part of Cassandra 3.x which means if we were to upgrade JG to use Cassandra-3.x, we'll be in good shape.

If anyone on the list is knowledgeable (LaRocque, Broecheler from git log) about this, please let me know if this approach will work.


Looking at the commit history since then, there are a number of additions but at its heart, it looks like that code is using the Datastax Cassandra driver to communicate with the cluster. The other JanusGraph CQL PR that is in-flight [2] brings this driver in at version 3.1.4. Looking at the compatibility table, that should be compatible with Cassandra 3.0+[3]. What would you think about basing your work off of that branch to see if you can get something up and running?

We have been looking at that contribution, but we feel like that it is more geared toward the OLTP like queries and it is yet another variable into an already high combinatoric complexity of dependencies. So, for now, we'll not rely on cql-backend branch changes.


Bumping the Janus dependency to 3.0 may be necessary, but that would most likely cause problems for folks who were running Cassandra in embedded mode. I'm not sure if anyone does that (ie. connecting using the C* apis vs. thrift, astyanax drivers with Janus & Cassandra in the same JVM), but if you do, speak up! I think for the moment it would be good to see if we could get this working without the version bump.

If the plan above works, then we just may have the best of both the worlds, because the embedded Cassandra-2.x will continue to work.

Makes sense?

Regards,
Kedar
 

Thanks for all the work on this,
Ted

[3] https://docs.datastax.com/en/developer/driver-matrix/doc/javaDrivers.html


On Wednesday, May 3, 2017 at 8:34:51 AM UTC-5, Kedar Mhaswade wrote:
Hello all,

See Issue-172 whose synopsis is: CassandraBinaryRecordReader not compatible with Cassandra 3.0+. There are a few comments and several useful links on the bug report that I have been discussing with Ted Wilmes. I have also asked Cassandra developers for advice.

It appears to me that we'll have to make JanusGraph require Cassandra-3 because of this issue. 

Thoughts, comments?

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-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



Re: [DISCUSS] 0.1.1 point fix release

Rafael Fernandes <luizr...@...>
 

+1


Re: JanusGraph and Cassandra-3 (issue 172)

Kedar Mhaswade <ke...@...>
 

Hi Ted,

Thanks for your encouragement. Some responses inline.


On Wed, May 3, 2017 at 9:51 AM, Ted Wilmes <twi...@...> wrote:
Hi Kedar,
Thanks for bringing this discussion over to the dev list. I think it'll benefit from the wider audience. If I read things correctly, I think that CqlRecordReader is available in 2.1 [1].

Correct. This comes via the cassandra-all-2.1.9 dependency that JanusGraph right now has. 
 
Perhaps we could see if it'll work against Cassandra 3?

It's the path that we are inclined toward taking. In Cassandra 2.x, there was a class CassandraServer which had methods like execute_cql_query, execute_cql3_query and so on that used to handle the CQL queries (CassandraServer was in a package named erroneously as org.apache.cassandra.thrift, a thift subpackage class handling CQL queries!  -- looking at you, Cassandra devs). In Cassandra 3.x, CassandraServer class is gone, but hopefully the actual CQL queries would be handled in a backward compatible manner by its reincarnation. 

That way, all the unit tests etc. will continue to run against the embedded Cassandra-2.x and in real life JG can speak with Cassandra-3.x at least for analytic queries (issued via the janusgraph-hadoop-parent/org.janusgraph.hadoop.formats.cassandra package). 

Thus, if CQL server implementation inside of Cassandra-3.x is backward compatible with the Cassandra-2.1.9 client used by hadoop classes in JanusGraph, we should be (barely) covered ;). This also lets JanusGraph not require Cassandra-3.x.

To be a little more concrete, I am planning to take a shot at reimplementing the logic in org.janusgraph.hadoop.formats.cassandra.CassandraBinaryRecordReader and org.janusgraph.hadoop.formats.cassandra.CassandraBinaryInputFormat by wrapping the org.apache.cassandra.hadoop.cql3.CqlRecordReader instead of org.apache.cassandra.hadoop.ColumnFamilyRecordReader (A Cassandra-2.x class which really is the problem because that embodies the incompatible schema change and of course is gone in Cassandra-3.x -- see my email to Cassandra devs). We hope that this change is going to be fairly localized.

Another data point is that org.apache.cassandra.hadoop.cql3.CqlRecordReader is part of Cassandra 3.x which means if we were to upgrade JG to use Cassandra-3.x, we'll be in good shape.

If anyone on the list is knowledgeable (LaRocque, Broecheler from git log) about this, please let me know if this approach will work.


Looking at the commit history since then, there are a number of additions but at its heart, it looks like that code is using the Datastax Cassandra driver to communicate with the cluster. The other JanusGraph CQL PR that is in-flight [2] brings this driver in at version 3.1.4. Looking at the compatibility table, that should be compatible with Cassandra 3.0+[3]. What would you think about basing your work off of that branch to see if you can get something up and running?

We have been looking at that contribution, but we feel like that it is more geared toward the OLTP like queries and it is yet another variable into an already high combinatoric complexity of dependencies. So, for now, we'll not rely on cql-backend branch changes.


Bumping the Janus dependency to 3.0 may be necessary, but that would most likely cause problems for folks who were running Cassandra in embedded mode. I'm not sure if anyone does that (ie. connecting using the C* apis vs. thrift, astyanax drivers with Janus & Cassandra in the same JVM), but if you do, speak up! I think for the moment it would be good to see if we could get this working without the version bump.

If the plan above works, then we just may have the best of both the worlds, because the embedded Cassandra-2.x will continue to work.

Makes sense?

Regards,
Kedar
 

Thanks for all the work on this,
Ted

[3] https://docs.datastax.com/en/developer/driver-matrix/doc/javaDrivers.html


On Wednesday, May 3, 2017 at 8:34:51 AM UTC-5, Kedar Mhaswade wrote:
Hello all,

See Issue-172 whose synopsis is: CassandraBinaryRecordReader not compatible with Cassandra 3.0+. There are a few comments and several useful links on the bug report that I have been discussing with Ted Wilmes. I have also asked Cassandra developers for advice.

It appears to me that we'll have to make JanusGraph require Cassandra-3 because of this issue. 

Thoughts, comments?

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-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [DISCUSS] 0.1.1 point fix release

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

+1


Re: DynamoDB Titan->JanusGraph->Titan Upgrade-Downgrade test results

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

Thank you for sharing, Jason. This is awesome!
It means that the upgrade/downgrade test worked flawlessly! AWESOME!!
Alex


On Thursday, May 4, 2017 at 1:59:53 AM UTC+9, Jason Plurad wrote:
That was an error in the Titan docs. It is corrected in the JanusGraph, see bleow:

pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select('god', 'place')
pluto
= g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select('god', 'place').by('name')


On Wednesday, May 3, 2017 at 12:50:15 PM UTC-4, Alexander Patrikalakis wrote:
gremlin> :> pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select()
Could not find which method select() to invoke from this list:
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String)
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String, java.lang.String, [Ljava.lang.String;)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.prNcess.traversal.Pop, java.lang.String, java.lang.String, [Ljava.lang.String;)
gremlin> tack trace? [yN] [A
gremlin> :> pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select().by('name')
Could not find which method select() to invoke from this list:
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String)
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String, java.lang.String, [Ljava.lang.String;)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String, java.lang.String, [Ljava.lang.String;)
Display stack trace? [yN] N


Re: [DISCUSS] 0.1.1 point fix release

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

With the release process being better understood now that we've done one, a 72 hour voting period sounds fine.


On Wednesday, May 3, 2017 at 12:45:58 PM UTC-4, Alexander Patrikalakis wrote:
Its a related change because the meaning of ID_STORE_NAME is no longer static:
getting pulled from config instead, so had to move away from static init.

On Wednesday, May 3, 2017 at 10:48:31 PM UTC+9, Ted Wilmes wrote:
That id issue is serious, so I'd agree that a 0.1.1 release sooner rather than later is a good idea. As far as process goes, we could probably drop the vote down to the usual 72 hours but I'd be hesitant to go any shorter than that.

One question, I was looking at the commits since the 0.1.0 release and noticed updates to the HBaseStoreManager as part of the ID name update, were those just stylistic updates or also related to to configurable ids? Here's one of them: https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR329.

Thanks,
Ted

On Tuesday, May 2, 2017 at 4:01:30 PM UTC-5, Alexander Patrikalakis wrote:
I would like to propose a 0.1.1 bugfix release to address the titan_ids->janusgraph_ids name change as well as the bug fix to the vertexCentricQuery test.
Given that 0.1.0 was already given quite a lot of scrutiny, can we use a streamlined process for bugfix releases? Or the full process?


Re: DynamoDB Titan->JanusGraph->Titan Upgrade-Downgrade test results

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

That was an error in the Titan docs. It is corrected in the JanusGraph, see bleow:

pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select('god', 'place')
pluto
= g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select('god', 'place').by('name')


On Wednesday, May 3, 2017 at 12:50:15 PM UTC-4, Alexander Patrikalakis wrote:
gremlin> :> pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select()
Could not find which method select() to invoke from this list:
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String)
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String, java.lang.String, [Ljava.lang.String;)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.prNcess.traversal.Pop, java.lang.String, java.lang.String, [Ljava.lang.String;)
gremlin> tack trace? [yN] [A
gremlin> :> pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select().by('name')
Could not find which method select() to invoke from this list:
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String)
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String, java.lang.String, [Ljava.lang.String;)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String, java.lang.String, [Ljava.lang.String;)
Display stack trace? [yN] N


Re: JanusGraph and Cassandra-3 (issue 172)

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

Hi Kedar,
Thanks for bringing this discussion over to the dev list. I think it'll benefit from the wider audience. If I read things correctly, I think that CqlRecordReader is available in 2.1 [1]. Perhaps we could see if it'll work against Cassandra 3? Looking at the commit history since then, there are a number of additions but at its heart, it looks like that code is using the Datastax Cassandra driver to communicate with the cluster. The other JanusGraph CQL PR that is in-flight [2] brings this driver in at version 3.1.4. Looking at the compatibility table, that should be compatible with Cassandra 3.0+[3]. What would you think about basing your work off of that branch to see if you can get something up and running?

Bumping the Janus dependency to 3.0 may be necessary, but that would most likely cause problems for folks who were running Cassandra in embedded mode. I'm not sure if anyone does that (ie. connecting using the C* apis vs. thrift, astyanax drivers with Janus & Cassandra in the same JVM), but if you do, speak up! I think for the moment it would be good to see if we could get this working without the version bump.

Thanks for all the work on this,
Ted


On Wednesday, May 3, 2017 at 8:34:51 AM UTC-5, Kedar Mhaswade wrote:
Hello all,

See Issue-172 whose synopsis is: CassandraBinaryRecordReader not compatible with Cassandra 3.0+. There are a few comments and several useful links on the bug report that I have been discussing with Ted Wilmes. I have also asked Cassandra developers for advice.

It appears to me that we'll have to make JanusGraph require Cassandra-3 because of this issue. 

Thoughts, comments?

Regards,
Kedar


Re: DynamoDB Titan->JanusGraph->Titan Upgrade-Downgrade test results

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

gremlin> :> pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select()
Could not find which method select() to invoke from this list:
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String)
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String, java.lang.String, [Ljava.lang.String;)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.prNcess.traversal.Pop, java.lang.String, java.lang.String, [Ljava.lang.String;)
gremlin> tack trace? [yN] [A
gremlin> :> pluto = g.V().has('name', 'pluto').next(); g.V(pluto).out('brother').as('god').out('lives').as('place').select().by('name')
Could not find which method select() to invoke from this list:
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String)
  public org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(java.lang.String, java.lang.String, [Ljava.lang.String;)
  public transient org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversal#select(org.apache.tinkerpop.gremlin.process.traversal.Pop, java.lang.String, java.lang.String, [Ljava.lang.String;)
Display stack trace? [yN] N


DynamoDB Titan->JanusGraph->Titan Upgrade-Downgrade test results

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

The actual labor involved in the upgrade-downgrade test is around an hour, but there were some bugs in the template that set me back about five hours.
Anyway, I performed the test against Titan 1.0.0 and JanusGraph 0.1.0 and it was successful for the most part.
Seems like there is an issue with the select() method in Titan 1.0.0? Should I be worried about this? I will try the Graph of the Gods walkthrough only using Titan to read and write and report back here.

https://github.com/awslabs/dynamodb-titan-storage-backend/issues/167

Cheers
Alex


Re: [DISCUSS] 0.1.1 point fix release

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

Its a related change because the meaning of ID_STORE_NAME is no longer static:
https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR333
getting pulled from config instead, so had to move away from static init.


On Wednesday, May 3, 2017 at 10:48:31 PM UTC+9, Ted Wilmes wrote:
That id issue is serious, so I'd agree that a 0.1.1 release sooner rather than later is a good idea. As far as process goes, we could probably drop the vote down to the usual 72 hours but I'd be hesitant to go any shorter than that.

One question, I was looking at the commits since the 0.1.0 release and noticed updates to the HBaseStoreManager as part of the ID name update, were those just stylistic updates or also related to to configurable ids? Here's one of them: https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR329.

Thanks,
Ted

On Tuesday, May 2, 2017 at 4:01:30 PM UTC-5, Alexander Patrikalakis wrote:
I would like to propose a 0.1.1 bugfix release to address the titan_ids->janusgraph_ids name change as well as the bug fix to the vertexCentricQuery test.
Given that 0.1.0 was already given quite a lot of scrutiny, can we use a streamlined process for bugfix releases? Or the full process?


Re: [DISCUSS] 0.1.1 point fix release

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

That id issue is serious, so I'd agree that a 0.1.1 release sooner rather than later is a good idea. As far as process goes, we could probably drop the vote down to the usual 72 hours but I'd be hesitant to go any shorter than that.

One question, I was looking at the commits since the 0.1.0 release and noticed updates to the HBaseStoreManager as part of the ID name update, were those just stylistic updates or also related to to configurable ids? Here's one of them: https://github.com/JanusGraph/janusgraph/commit/faf50f21bf4ef211d4f7d3d8835f858a2d5ae17a#diff-56793e16022de6b261b0009358f328cbR329.

Thanks,
Ted


On Tuesday, May 2, 2017 at 4:01:30 PM UTC-5, Alexander Patrikalakis wrote:
I would like to propose a 0.1.1 bugfix release to address the titan_ids->janusgraph_ids name change as well as the bug fix to the vertexCentricQuery test.
Given that 0.1.0 was already given quite a lot of scrutiny, can we use a streamlined process for bugfix releases? Or the full process?


JanusGraph and Cassandra-3 (issue 172)

Kedar Mhaswade <ke...@...>
 

Hello all,

See Issue-172 whose synopsis is: CassandraBinaryRecordReader not compatible with Cassandra 3.0+. There are a few comments and several useful links on the bug report that I have been discussing with Ted Wilmes. I have also asked Cassandra developers for advice.

It appears to me that we'll have to make JanusGraph require Cassandra-3 because of this issue. 

Thoughts, comments?

Regards,
Kedar

1361 - 1380 of 1585