Date   

Re: [DISCUSS] Developer chat (+FoundationDB chat)

Debasish Kanhar <d.k...@...>
 

Makes sense. If we have enough persons interested in specific to a topic, we can create a separate channel for the same. :-)

I would say +1 for this.

If we can have Slack it will be lot better. Wider acceptance ratio I feel but anything is okay :-)

On Wednesday, 1 April 2020 12:18:39 UTC+5:30, Jan Jansen wrote:
+1 for this.

Besides Gitter, we should think also about Slack or Discord. 


  • Slack is much more common in the industry than Gitter.
  • Discord had gain speed in the open-source communities in the last years and also support Talk channels directly.

On Monday, March 30, 2020 at 12:40:23 PM UTC+2, Florian Hockmann wrote:
Hi,
we currently have a public chat on Gitter for JanusGraph that is mainly used for questions by users. I think it would be helpful to have another room to discuss about the development of JanusGraph. It should only be used for quick informal discussions as all formal decisions should be made here in the Google group where they get more visibility and people have more time to voice their opinion. But a chat makes it easier to have quick discussion or to coordinate bigger development tasks.

In addition to a general developer chat room, I think that it might also be useful in the long term to create rooms for certain areas of development, e.g., for the driver or for a specific backend. Contributors already asked for a chat to coordinate the development of the FoundationDB backend. So, I suggest that we also create a dedicated room for the FoundationDB backend which is kind of a special case as it's still in an early state, not an official backend (yet?) and there apparently already exist some attempts in different organizations to improve that backend which shows the need for improved coordination in my opinion.

Are there any concerns with this? Otherwise I'll go ahead and create the rooms.

TLDR: I suggest that we create two new rooms in our Gitter JanusGraph organization:
  1. JanusGraph Development
  2. JanusGraph FoundationDB
Regards,
Florian


Re: [VOTE] JanusGraph 0.5.1 release

Oleksandr Porunov <alexand...@...>
 

I have submitted PR to fix the problem with default gremlin-server : https://github.com/JanusGraph/janusgraph/pull/2067

I also checked that gremlin server has the same problem with version 0.4.0. Also, it doesn't even start by default in 0.3.1 version. So, this bug is here for a long time.
I also agree on your suggestions about naming of releases. Maybe it is better to keep `janusgraph-0.5.1.zip` as a full janusgraph version and `janusgraph-0.5.1-truncated.zip` as a truncated version.

On Wednesday, April 1, 2020 at 9:54:50 AM UTC-7, Florian Hockmann wrote:
It fails for both versions. The big problem I see with this is that our docs say about this:

By default, this will instruct JanusGraph to use it's own inmemory backend instead of a dedicated database server.

so it should really not expect some externally running Cassandra or Elasticsearch. This problem was probably already present at least in 0.5.0, but I think that it gets worse with this release because we now have the truncated zip archive as the default distribution (it's named just janusgraph-[version].zip after all and not [janusgraph-[version]-truncated.zip) and that doesn't contain a method any more to easily start JanusGraph Server like it's described in the docs. For the full distribution, users could at least switch back to janusgraph.sh which should still work.
That is why I think that we should really fix that before releasing a truncated distribution or if we really want to release now, then we should treat the full archive as the default distribution and the truncated one as an addition for users who want to save some disk space and who know that they have to manage backends on their own.

Am Mittwoch, 1. April 2020 18:21:14 UTC+2 schrieb Oleksandr Porunov:
Florian, thank you for catching it. I didn't check yet but does "./bin/gremlin-server.sh start" fails on both truncated and full JanusGraph versions? I.e. I assume you should run CQL and ES externally when you are using a truncated JanusGraph version. We already have information in our documentation that "This requires to download janusgraph-full-0.5.1.zip instead of the default janusgraph-0.5.1.zip". I.e. I assume that it is OK that default ./bin/gremlin-server.sh start fails in truncated version because it is described in the documentation.
Also, if it fails in full version also, does it work in any JanusGraph version (i.e. 0.4.0 or 0.3.0)? In case it doesn't work with older JanusGraph version, then we don't introduce any new bugs and thus the bugfix can be postponed for the future releases (unless the bug can be fixed quickly or the bug is critical). That said, I didn't yet check those bugs you have described, I will try to check them later.

On Wednesday, April 1, 2020 at 7:26:46 AM UTC-7, Florian Hockmann wrote:
I just tried both zip archives, following our docs on local installation that simply starts JanusGraph Server with ./bin/gremlin-server.sh start. This fails silently which can be noticed when one tries to connect to that from the console with :remote connect as that results in this error message: gremlin-groovy is not an available GremlinScriptEngine

This seems to be caused by the fact that gremlin-server.sh uses the default gremlin-server.yaml which uses CQL and ES.

If we now point users at gremlin-server.sh to get started instead of janusgraph.sh as that isn't included in the truncated version, then we need to make sure that this actually works out of the box.

So, my VOTE is -1.

Am Samstag, 28. März 2020 23:27:49 UTC+1 schrieb Jan Jansen:
Hi,
I have tested the truncated binary distribution, using the a pre-built docker image of janusgraph.
My vote is +1.

Greetings,
Jan

On Thursday, March 26, 2020 at 2:21:41 AM UTC+1, Oleksandr Porunov wrote:
Hello,

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

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-full-0.5.1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.5.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.5/docs/changelog.md#version-051-release-date-march-25-2020

This [VOTE] will open for the next 3 days --- closing Saturday, March 29, 2020 at 01:30 AM GMT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [VOTE] JanusGraph 0.5.1 release

Florian Hockmann <f...@...>
 

It fails for both versions. The big problem I see with this is that our docs say about this:

By default, this will instruct JanusGraph to use it's own inmemory backend instead of a dedicated database server.

so it should really not expect some externally running Cassandra or Elasticsearch. This problem was probably already present at least in 0.5.0, but I think that it gets worse with this release because we now have the truncated zip archive as the default distribution (it's named just janusgraph-[version].zip after all and not [janusgraph-[version]-truncated.zip) and that doesn't contain a method any more to easily start JanusGraph Server like it's described in the docs. For the full distribution, users could at least switch back to janusgraph.sh which should still work.
That is why I think that we should really fix that before releasing a truncated distribution or if we really want to release now, then we should treat the full archive as the default distribution and the truncated one as an addition for users who want to save some disk space and who know that they have to manage backends on their own.

Am Mittwoch, 1. April 2020 18:21:14 UTC+2 schrieb Oleksandr Porunov:
Florian, thank you for catching it. I didn't check yet but does "./bin/gremlin-server.sh start" fails on both truncated and full JanusGraph versions? I.e. I assume you should run CQL and ES externally when you are using a truncated JanusGraph version. We already have information in our documentation that "This requires to download janusgraph-full-0.5.1.zip instead of the default janusgraph-0.5.1.zip". I.e. I assume that it is OK that default ./bin/gremlin-server.sh start fails in truncated version because it is described in the documentation.
Also, if it fails in full version also, does it work in any JanusGraph version (i.e. 0.4.0 or 0.3.0)? In case it doesn't work with older JanusGraph version, then we don't introduce any new bugs and thus the bugfix can be postponed for the future releases (unless the bug can be fixed quickly or the bug is critical). That said, I didn't yet check those bugs you have described, I will try to check them later.

On Wednesday, April 1, 2020 at 7:26:46 AM UTC-7, Florian Hockmann wrote:
I just tried both zip archives, following our docs on local installation that simply starts JanusGraph Server with ./bin/gremlin-server.sh start. This fails silently which can be noticed when one tries to connect to that from the console with :remote connect as that results in this error message: gremlin-groovy is not an available GremlinScriptEngine

This seems to be caused by the fact that gremlin-server.sh uses the default gremlin-server.yaml which uses CQL and ES.

If we now point users at gremlin-server.sh to get started instead of janusgraph.sh as that isn't included in the truncated version, then we need to make sure that this actually works out of the box.

So, my VOTE is -1.

Am Samstag, 28. März 2020 23:27:49 UTC+1 schrieb Jan Jansen:
Hi,
I have tested the truncated binary distribution, using the a pre-built docker image of janusgraph.
My vote is +1.

Greetings,
Jan

On Thursday, March 26, 2020 at 2:21:41 AM UTC+1, Oleksandr Porunov wrote:
Hello,

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

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-full-0.5.1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.5.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.5/docs/changelog.md#version-051-release-date-march-25-2020

This [VOTE] will open for the next 3 days --- closing Saturday, March 29, 2020 at 01:30 AM GMT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [VOTE] JanusGraph 0.5.1 release

Oleksandr Porunov <alexand...@...>
 

Florian, thank you for catching it. I didn't check yet but does "./bin/gremlin-server.sh start" fails on both truncated and full JanusGraph versions? I.e. I assume you should run CQL and ES externally when you are using a truncated JanusGraph version. We already have information in our documentation that "This requires to download janusgraph-full-0.5.1.zip instead of the default janusgraph-0.5.1.zip". I.e. I assume that it is OK that default ./bin/gremlin-server.sh start fails in truncated version because it is described in the documentation.
Also, if it fails in full version also, does it work in any JanusGraph version (i.e. 0.4.0 or 0.3.0)? In case it doesn't work with older JanusGraph version, then we don't introduce any new bugs and thus the bugfix can be postponed for the future releases (unless the bug can be fixed quickly or the bug is critical). That said, I didn't yet check those bugs you have described, I will try to check them later.

On Wednesday, April 1, 2020 at 7:26:46 AM UTC-7, Florian Hockmann wrote:
I just tried both zip archives, following our docs on local installation that simply starts JanusGraph Server with ./bin/gremlin-server.sh start. This fails silently which can be noticed when one tries to connect to that from the console with :remote connect as that results in this error message: gremlin-groovy is not an available GremlinScriptEngine

This seems to be caused by the fact that gremlin-server.sh uses the default gremlin-server.yaml which uses CQL and ES.

If we now point users at gremlin-server.sh to get started instead of janusgraph.sh as that isn't included in the truncated version, then we need to make sure that this actually works out of the box.

So, my VOTE is -1.

Am Samstag, 28. März 2020 23:27:49 UTC+1 schrieb Jan Jansen:
Hi,
I have tested the truncated binary distribution, using the a pre-built docker image of janusgraph.
My vote is +1.

Greetings,
Jan

On Thursday, March 26, 2020 at 2:21:41 AM UTC+1, Oleksandr Porunov wrote:
Hello,

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

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-full-0.5.1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.5.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.5/docs/changelog.md#version-051-release-date-march-25-2020

This [VOTE] will open for the next 3 days --- closing Saturday, March 29, 2020 at 01:30 AM GMT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [VOTE] JanusGraph 0.5.1 release

Florian Hockmann <f...@...>
 

I just tried both zip archives, following our docs on local installation that simply starts JanusGraph Server with ./bin/gremlin-server.sh start. This fails silently which can be noticed when one tries to connect to that from the console with :remote connect as that results in this error message: gremlin-groovy is not an available GremlinScriptEngine

This seems to be caused by the fact that gremlin-server.sh uses the default gremlin-server.yaml which uses CQL and ES.

If we now point users at gremlin-server.sh to get started instead of janusgraph.sh as that isn't included in the truncated version, then we need to make sure that this actually works out of the box.

So, my VOTE is -1.

Am Samstag, 28. März 2020 23:27:49 UTC+1 schrieb Jan Jansen:

Hi,
I have tested the truncated binary distribution, using the a pre-built docker image of janusgraph.
My vote is +1.

Greetings,
Jan

On Thursday, March 26, 2020 at 2:21:41 AM UTC+1, Oleksandr Porunov wrote:
Hello,

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

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-full-0.5.1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.5.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.5/docs/changelog.md#version-051-release-date-march-25-2020

This [VOTE] will open for the next 3 days --- closing Saturday, March 29, 2020 at 01:30 AM GMT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [DISCUSS] Developer chat (+FoundationDB chat)

Jan Jansen <faro...@...>
 

+1 for this.

Besides Gitter, we should think also about Slack or Discord. 


  • Slack is much more common in the industry than Gitter.
  • Discord had gain speed in the open-source communities in the last years and also support Talk channels directly.

On Monday, March 30, 2020 at 12:40:23 PM UTC+2, Florian Hockmann wrote:
Hi,
we currently have a public chat on Gitter for JanusGraph that is mainly used for questions by users. I think it would be helpful to have another room to discuss about the development of JanusGraph. It should only be used for quick informal discussions as all formal decisions should be made here in the Google group where they get more visibility and people have more time to voice their opinion. But a chat makes it easier to have quick discussion or to coordinate bigger development tasks.

In addition to a general developer chat room, I think that it might also be useful in the long term to create rooms for certain areas of development, e.g., for the driver or for a specific backend. Contributors already asked for a chat to coordinate the development of the FoundationDB backend. So, I suggest that we also create a dedicated room for the FoundationDB backend which is kind of a special case as it's still in an early state, not an official backend (yet?) and there apparently already exist some attempts in different organizations to improve that backend which shows the need for improved coordination in my opinion.

Are there any concerns with this? Otherwise I'll go ahead and create the rooms.

TLDR: I suggest that we create two new rooms in our Gitter JanusGraph organization:
  1. JanusGraph Development
  2. JanusGraph FoundationDB
Regards,
Florian


Re: [DISCUSS] Developer chat (+FoundationDB chat)

f.gri...@...
 

I think it's a good idea to have a separate room for each topic as long as it affects enough people to justify having it's own room. So maybe we can start with this one and add more on the fly when needed.
 

As for JanusGraph FoundationDB channel, do we want the new channel specific to single backend like FoundataionDB? Can we generalize that?


Re: New Storage backend - H2 MV store

ashwi...@...
 

Thanks, Dmitry

Let me get to work on this and post back when it's ready

--
Ashwin


On Monday, 30 March 2020 17:09:35 UTC+5:30, Dmitry Kovalev wrote:
Hi Ashwin,

Thank you for the offering.

I think it would be great if you could open source it in your own repo on github, and post links here and in users group. Also if you could share some more info on how it works, what features it supports, some performance tests and comparisons to berkeley backend, some practical limits (e.g. how much data can be stored in a single instance on a commodity machine) -- that might produce more upfront interest, i.e. more people would actually download and try it, and maybe contribute as well.

Once you are satisfied that it has reached production quality, we could initiate a discussion here to have Janusgraph documentation updated to list your new backend and provide a sample configuration.

Thanks,
Dmitry

On Sun, 29 Mar 2020 at 16:27, <a...@...> wrote:
Hi, 

We needed an embeddable backing store for Janus on one of our products. Since the Berkley JE license is restrictive , we ended up writing a quick implementation on top of MV store

The standard unit tests are passing and performance is good (at our scale) . I was wondering if this is something anyone else is interested in so we can make some effort to open source it. The implementation is in Kotlin though, but should be usable as a library.

--
Ashwin




--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/e01d2d3c-ccdf-4a2a-991a-d384861ff239%40googlegroups.com.


Re: New Storage backend - H2 MV store

Dmitry Kovalev <dk.g...@...>
 

Hi Ashwin,

Thank you for the offering.

I think it would be great if you could open source it in your own repo on github, and post links here and in users group. Also if you could share some more info on how it works, what features it supports, some performance tests and comparisons to berkeley backend, some practical limits (e.g. how much data can be stored in a single instance on a commodity machine) -- that might produce more upfront interest, i.e. more people would actually download and try it, and maybe contribute as well.

Once you are satisfied that it has reached production quality, we could initiate a discussion here to have Janusgraph documentation updated to list your new backend and provide a sample configuration.

Thanks,
Dmitry


On Sun, 29 Mar 2020 at 16:27, <ash...@...> wrote:
Hi, 

We needed an embeddable backing store for Janus on one of our products. Since the Berkley JE license is restrictive , we ended up writing a quick implementation on top of MV store

The standard unit tests are passing and performance is good (at our scale) . I was wondering if this is something anyone else is interested in so we can make some effort to open source it. The implementation is in Kotlin though, but should be usable as a library.

--
Ashwin




--
You received this message because you are subscribed to the Google Groups "JanusGraph developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/e01d2d3c-ccdf-4a2a-991a-d384861ff239%40googlegroups.com.


Re: [DISCUSS] Developer chat (+FoundationDB chat)

Debasish Kanhar <d.k...@...>
 

+1 for this.

I have always wanted a Developer's chat room, so that a quick informal question can be asked and be replied faster. Maybe even Slack will do like we have for ScyllaDB. Such way that, if there are any developers out there, they can also post remainders on Chat room that a new PR request is Pending can up for review in case Developers/Committers/Maintainers miss it out by mistake :-) (Like @Florian, once you get time, can you have a look at the updated PR for Janusgraph-python after resolving lot of Codacy issues? and ignoring aFalse positives)

As for JanusGraph FoundationDB channel, do we want the new channel specific to single backend like FoundataionDB? Can we generalize that? As per the posts I'm seeing on groups, a lot of people are adding new and new backends based on their use cases like SnowFlake, FoundataionDB, H2 MV Store, DynamoDB, EBay DB etc. If we have single chatroom for backend related addition development question, we can streamline a lot of  questions as well, as a lot of question related to adding new backend are similar. What do you say?

On Monday, 30 March 2020 16:10:23 UTC+5:30, Florian Hockmann wrote:
Hi,
we currently have a public chat on Gitter for JanusGraph that is mainly used for questions by users. I think it would be helpful to have another room to discuss about the development of JanusGraph. It should only be used for quick informal discussions as all formal decisions should be made here in the Google group where they get more visibility and people have more time to voice their opinion. But a chat makes it easier to have quick discussion or to coordinate bigger development tasks.

In addition to a general developer chat room, I think that it might also be useful in the long term to create rooms for certain areas of development, e.g., for the driver or for a specific backend. Contributors already asked for a chat to coordinate the development of the FoundationDB backend. So, I suggest that we also create a dedicated room for the FoundationDB backend which is kind of a special case as it's still in an early state, not an official backend (yet?) and there apparently already exist some attempts in different organizations to improve that backend which shows the need for improved coordination in my opinion.

Are there any concerns with this? Otherwise I'll go ahead and create the rooms.

TLDR: I suggest that we create two new rooms in our Gitter JanusGraph organization:
  1. JanusGraph Development
  2. JanusGraph FoundationDB
Regards,
Florian


[DISCUSS] Developer chat (+FoundationDB chat)

Florian Hockmann <f...@...>
 

Hi,
we currently have a public chat on Gitter for JanusGraph that is mainly used for questions by users. I think it would be helpful to have another room to discuss about the development of JanusGraph. It should only be used for quick informal discussions as all formal decisions should be made here in the Google group where they get more visibility and people have more time to voice their opinion. But a chat makes it easier to have quick discussion or to coordinate bigger development tasks.

In addition to a general developer chat room, I think that it might also be useful in the long term to create rooms for certain areas of development, e.g., for the driver or for a specific backend. Contributors already asked for a chat to coordinate the development of the FoundationDB backend. So, I suggest that we also create a dedicated room for the FoundationDB backend which is kind of a special case as it's still in an early state, not an official backend (yet?) and there apparently already exist some attempts in different organizations to improve that backend which shows the need for improved coordination in my opinion.

Are there any concerns with this? Otherwise I'll go ahead and create the rooms.

TLDR: I suggest that we create two new rooms in our Gitter JanusGraph organization:
  1. JanusGraph Development
  2. JanusGraph FoundationDB
Regards,
Florian


Re: Migrate to travis-ci.com

Jan Jansen <faro...@...>
 

I'm seeing the same issues with travis-ci.org. If you use travis-ci.com, you also get support actions (tab in a pr).

Vote +1

On Wednesday, March 25, 2020 at 6:25:11 PM UTC+1, Oleksandr Porunov wrote:
Currently we are using travis-ci.org and I often notice periodic problems with that. Sometimes workers stop to process any computation, sometimes website doesn't work (on maintenance), sometimes ability to restart jobs disappear and I need to sign out and then sign in to fix that.
I don't know if those problems will occur when switching to `.com` but at least I noticed last time that when `.org` was under maintenance, `.com` version was working properly.
I would suggest to give it a try and use `.com` version for a while to check if it will work better for our use cases.


Jansugraph0.4 & ES6.x integration issue

kiran.pa...@...
 

Hi,

During an index creation in ES serve , there is a default type is getting added to “mappings”  by default during index creation .

Later when the  application initiates a “PUT” rest method  update the mapping , ES send an error(400 BAD request) and rejects the mapping update since ES 6 and above doesn’t allow multiple types in a mapping.


Rejecting mapping update to [customerIndex] as the final mapping would have more than 1 type: [customerIndex, logs]}


Does anyone integrated JanusGraph0.4.x with ES6.x and Cassandra, please share the configuration once.

Thanks,
Kiran


New Storage backend - H2 MV store

ash...@...
 

Hi, 

We needed an embeddable backing store for Janus on one of our products. Since the Berkley JE license is restrictive , we ended up writing a quick implementation on top of MV store

The standard unit tests are passing and performance is good (at our scale) . I was wondering if this is something anyone else is interested in so we can make some effort to open source it. The implementation is in Kotlin though, but should be usable as a library.

--
Ashwin





Re: [VOTE] JanusGraph 0.5.1 release

Jan Jansen <faro...@...>
 

Hi,
I have tested the truncated binary distribution, using the a pre-built docker image of janusgraph.
My vote is +1.

Greetings,
Jan

On Thursday, March 26, 2020 at 2:21:41 AM UTC+1, Oleksandr Porunov wrote:
Hello,

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

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-full-0.5.1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.5.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.5/docs/changelog.md#version-051-release-date-march-25-2020

This [VOTE] will open for the next 3 days --- closing Saturday, March 29, 2020 at 01:30 AM GMT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Re: [VOTE] JanusGraph 0.5.1 release

nicolas...@...
 

Hi,
I have tested the truncated binary distribution.
My vote is +1

Regards,
Nicolas


Le jeudi 26 mars 2020 02:21:41 UTC+1, Oleksandr Porunov a écrit :
Hello,

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

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-full-0.5.1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.5.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.5/docs/changelog.md#version-051-release-date-march-25-2020

This [VOTE] will open for the next 3 days --- closing Saturday, March 29, 2020 at 01:30 AM GMT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


[VOTE] JanusGraph 0.5.1 release

Oleksandr Porunov <alexand...@...>
 

Hello,

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

The release artifacts can be found at this location:
        https://github.com/JanusGraph/janusgraph/releases/tag/v0.5.1

A full binary distribution is provided for user convenience:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-full-0.5.1.zip

A truncated binary distribution is provided:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1.zip

The GPG key used to sign the release artifacts is available at:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/KEYS

The docs can be found here:
        https://github.com/JanusGraph/janusgraph/releases/download/v0.5.1/janusgraph-0.5.1-doc.zip

The release tag in Git can be found here:
        https://github.com/JanusGraph/janusgraph/tree/v0.5.1

The release notes are available here:
        https://github.com/JanusGraph/janusgraph/blob/v0.5/docs/changelog.md#version-051-release-date-march-25-2020

This [VOTE] will open for the next 3 days --- closing Saturday, March 29, 2020 at 01:30 AM GMT.
All are welcome to review and vote on the release, but only votes from TSC members are binding.
My vote is +1.

Thank you,
Oleksandr Porunov


Migrate to travis-ci.com

Oleksandr Porunov <alexand...@...>
 

Currently we are using travis-ci.org and I often notice periodic problems with that. Sometimes workers stop to process any computation, sometimes website doesn't work (on maintenance), sometimes ability to restart jobs disappear and I need to sign out and then sign in to fix that.
I don't know if those problems will occur when switching to `.com` but at least I noticed last time that when `.org` was under maintenance, `.com` version was working properly.
I would suggest to give it a try and use `.com` version for a while to check if it will work better for our use cases.


[RESULT][VOTE] JanusGraph 0.5.0 release

Oleksandr Porunov <alexand...@...>
 

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, Ted Wilmes)
0   (0)
-1  (0)

NON-BINDING VOTES:

+1 (1 -- Nicolas)
0  (0)
-1 (0)

Thank you very much,
Oleksandr Porunov


Re: [VOTE] JanusGraph 0.5.0 release

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

Vote +1


On Fri, Mar 20, 2020, 7:06 AM 'Jan Jansen' via JanusGraph developers <janusgr...@...> wrote:
Vote +1

On Wednesday, March 18, 2020 at 7:28:18 PM UTC+1, Oleksandr Porunov wrote:
Thank you Jan.
Yes, I think we can release 0.5.1 as a truncated version short after 0.5.0 release.

On Wednesday, March 18, 2020 at 7:04:43 AM UTC-7, Jan Jansen wrote:
I am OK with it. I would prefer to work on truncated short after this release and release 0.5.1 also as truncated release.

If opened two PRs for the docker images which are required for releasing docker images for 0.5.

I think tomorrow will able give a vote. I have to check the hadoop part.

On Tuesday, March 17, 2020 at 4:24:43 PM UTC+1, Oleksandr Porunov wrote:
Hi Jan,

I think that it isn't a big problem that current release is 2 times bigger than past releases. Of course we can try to ship also truncated releases but it looks more like a new feature. We actually can add a truncated opinion to all current JanusGraph releases but I think we need to discuss it in a separate thread. I don't think we should postpone the release because of its size (0.5 GB) but if you think that it is a problem and we should also add a truncated option to this release, I am OK with it.

--
You received this message because you are subscribed to a topic in the Google Groups "JanusGraph developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/janusgraph-dev/ejs-BAbu7wM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to janusgr...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/6d1957f4-1241-4565-94df-9fa56002f105%40googlegroups.com.

241 - 260 of 1585