On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new Technical Steering Committee member on the project! Boxuan Li has provided major contributions and has

Hi Jan, I think you could forward this to the user mailing list as well. Maybe janusgraph-hbase users could shed some light. I personally don’t have any opinion

Hi I looked into the Hbase 1 support after Porunov asked why I want to drop if the builds are passing: https://github.com/JanusGraph/janusgraph/pull/2213#issuecomment-861620348.It seems that we stop

1.0.0 sounds good to me. Maybe we can target 1.0.0 after this 0.6.0 release. I think we'd better not rename the incoming release from 0.6.0 to 1.0.0, because it contains many new changes and may take

Hi, I would like to start a discussion about JanusGraph versioning. Right now we have the next versioning: <GA indicator?>.<features and breaking changes>.<patch> So, for GA indicator we always have

Hello, Thanks to all who attended the meetup yesterday. If you weren't able to make it, you can find the recording at: https://www.experoinc.com/online-seminar/janusgraph-community-meetup. Thanks to

Hi Boxuan, Yes, definitely. I'll post this under presentations on janusgraph.org. Also, I hadn't posted meetup 3 on there yet and finally tracked the link down, so that will also be up there

Hi Ted, Thanks for organizing this! Do you have plans to record & release the video after the meetup? 10:30 ET is a bit late for some regions in APAC, so it would be great if there would be a video

Hello, We will be hosting a community meetup next week on Tuesday, May 18th at 9:30 central/10:30 eastern. We have a great set of speakers who will be discussing all things JanusGraph OLAP: * Hadoop

Hi Florian! That definitely sounds like a promising idea. You are most likely not the only one requiring consistency between storage and index data. In general, my advice is to start with a test case

Hi! Currently JanusGraph's philosophy is to fail transactions only if the primary persistence fails and allow failures in secondary persistence. According to

As Tinkerpop is very close for a release, I'm proposing to delay JanusGraph 0.6.0 release, so that we could ship 0.6.0 release of JanusGraph with either 3.4.11 or 3.5.0 version of Tinkerpop. I assume,

It sounds like tinkerpop will start in one week with the release. https://lists.apache.org/thread.html/r54ceb07f60b246342f5f2d9a09d50034c502012025eb88534fd9fa3f%40%3Cdev.tinkerpop.apache.org%3E

Yeah that makes sense. I saw you said “unreplicated” thus wondered. I am not familiar with how `system_properties` is handled, but just want to point out that it is very difficult if not

Hi Boxuan Li We are using RF3. What I meant is that essentially the data for system_properties is going to a single partition. Due to RF3, this partition is replicated 3 times. Does this

Hi @sauverma, I am just curious: I noticed you said "there is only 1 partition for system_properties unreplicated". Do you have storage.cql.replication-factor = 1?

Hi all Updates on this issue - We found that the periodic removal of system_properties (while the ingestion is running) leads to graph corruption (mentioned at high level at

What do you think? Sounds great Would such a deadline be OK? I think it is good idea to have a deadline. Von: janusgraph-dev@... <janusgraph-dev@...> im Auftrag von Oleksandr Porunov

I am good with waiting for TinkerPop 3.4.11 or 3.5.0 if we expect those releases soon, but I don't want to delay 0.6.0 release too much because the community sometimes asks for the release. Also, if

If we wait for TinkerPop 3.5.0 (or 3.4.11), we can probably also release the configurable batch sizes in 0.6.0 which should bring a noticable performance gain if used properly. Kind regards, Florian