This vote is now closed with a total of 3 +1s, no +0s and no -1s. The results are: BINDING VOTES: +1 (3 -- Oleksandr Porunov, Florian Hockmann, Jan Jansen) 0 (0) -1 (0) NON-BINDING VOTES: +1 (0) 0

I did a quick test of both binary distributions. VOTE +1 I think could work on releasing an extra distribution for hbase1 which is used for google bigtable, if I'm correct.

I checked the release notes and did a quick test of both binary distributions. VOTE +1 Am Mittwoch, 6. Mai 2020 02:51:49 UTC+2 schrieb Oleksandr Porunov:

Hello, We are happy to announce that JanusGraph 0.5.2 is ready for release. The release artifacts can be found at this location: https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.2 A

We are using jansugraph with Cassandra + ES combination , we are doing data ingestion with OLAP mode , since we are submitting batch requests , and we are using commit method to commit the transaction

Hi Anjani, This is JanusGraph developers channel to discuss JanusGraph development process. You can get help with your issue in the next channel:

Hi All, We have a custom vertex program which find connected nodes. We have some unique requirement to remove some duplicate data, for that we are collecting all data using collectAsMap() method. But

Thanks for driving this, Florian

Thanks Pavel. I've tried all those, and those have helped me reduce the execution time by almost 50% along with query optimizations as well. But that's still slower for my use case. :-) I'm looking at

JG has three options to reduce number of queries https://docs.janusgraph.org/basics/configuration-reference/#query PROPERTY_PREFETCHING -- enabled by default USE_MULTIQUERY -- disabled by

I created the channel: https://gitter.im/janusgraph/janusgraph-dev You should all be able to join. I'll also create a PR to add it to our README.md. Am Mittwoch, 15. April 2020 14:16:36 UTC+2 schrieb

It looks like we have a wide consensus on starting a new channel for development discussions, but different opinions on whether we should directly create a dedicated channel for FoundationDB and also

Sorry I just saw this discussions. Thanks for pinging me, Misha. As Misha and Florian had mentioned, we did some investigating and exploring which "chat" tool we will use for JanusGraph. We chose

I think Misha has good arguments for staying on Gitter. I personally don't think that we need a high entry barrier for a developer chat as we currently also don't get many non-dev questions in the

For anyone following this thread. My primary query was to implement multi-get type implementation w.r.t. to my backend. Do check Marko's comment

This vote is now closed with a total of 4 +1s, no +0s and no -1s. The results are: BINDING VOTES: +1 (3 -- Oleksandr Porunov, Jan Jansen, Florian Hockmann) 0 (0) -1 (0) NON-BINDING VOTES: +1 (1 --

I thought about the separation of google groups. I think just a different channel of wouldn’t help because some people just ignore these rules. For example github issues, you have a template for

Are you trying to have the same separation on Gitter as we do with janusgraph-users@ and janusgraph-dev@ mailing lists? Would creating separate channels on Gitter not address this? Or are you saying

Hi Misra, Some of your reason are exactly the reason why I’m against Gitter. Currently Gitter is for JanusGraph just support chat. This channel would be hard to use for the developer focused talks.

So, we keep this VOTE thread for this release? In that case: I tested the new distributions by starting JanusGraph Server with the in-memory backend on both as described in the docs and then connected