1. janusgraph-dev@lists.lfaidata.foundation
  2. Messages
   Date   
Re: [janusgraph-foundationdb] - Repository cleanup questions

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

FYI, looks like there's already a PR to move files and update the packages. Additionally, Jan Jansen volunteered to work on the Travis CI config after the PR to add testcontainers is merged.


On Thu, Jul 16, 2020 at 1:07 AM Christopher Jackson <jackson.ch...@...> wrote:
Thanks so much for the guidance Misha and for creating the work items. I will start working on these and request you as a reviewer. 

--
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/42449c06-0460-4e19-bc1b-71acfdced7a8o%40googlegroups.com.
Re: [janusgraph-foundationdb] - Repository cleanup questions

Christopher Jackson <jackson.ch...@...>
 

Thanks so much for the guidance Misha and for creating the work items. I will start working on these and request you as a reviewer. 
Re: [DISCUSS] Revamp JanusGraph Management

"fa...@googlemail.com" <faro...@...>
 

Hi Oleksandr,

I started to work on a https://github.com/farodin91/janusgraph-grpc client/server for JanusGraph to management all parts of JanusGraph on of cause would be schema. Other parts are for example CFG, or index management.
My next step is integrate a basic gRPC client JanusGraph which allows us to get some basic information of running JanusGraph server. I will start to extend it by schema function step by step. The gRPC protocol can be later used to provide a tool to import and export the schema as JSON.

Greetings,
Jan

On Wednesday, July 15, 2020 at 12:23:44 PM UTC+2 Oleksandr Porunov wrote:
Hi,
As a follow up to this thread I also think it would be great if we could use DDL for schema definition.
I don't know yet the format which we should use (whether it should be gremlin query or some json / xml or something else).
Is there any updates regarding Schema Management?
Just to not do double work for Schema Management, I would like to know if someone was working on making DDL for schema. If so, were there any troubles? What format is better to use for schema definition?
Currently I am thinking about JSON format, something like:
[
  {
    type: vertexLabel,
    name: myVertexLabel
  },
  {
    type: edgeLabel,
    name: myEdgeLabel
    multiplicity: MANY2ONE
  },
  {
      type: propertyKey,
      dataType: String.class
      name: myProperty,
      cardinality: LIST
   },
   {
      type: compositeIndex,
      indexOnly: myVertexLabel,
      keys: [
         {
             name: myProperty
          }
      ]
   },
   {
      type: mixedIndex,
      keys: [
         {
             name: myProperty,
             parameters: [
                {
                     key: parameterKey,
                     value: parameterValue
                }
             ]
          }
      ]
    }
]

I didn't think much about schema definition, so I might miss some points. If you have any thoughts / suggestions on the format or how should this feature be implemented, it would be great. Also, I didn't work with GraphQL, so will check a little bit later if that format might be used as well.

Best regards,
Oleksandr

On Friday, February 28, 2020 at 8:30:21 PM UTC+2 fa...@... wrote:

An HTTP API would have the benefit of making the schema management available to users of the Gremlin server without the mentioned problems for making it accessible via Gremlin. As it would just expose the underlying Java API (current or a new one), it would be 

nice if the web service would be optional if JG is used embedded.


+1

One of my major concerns is to make JanusGraph more modular.

Re: [DISCUSS] Revamp JanusGraph Management

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

Hi,
As a follow up to this thread I also think it would be great if we could use DDL for schema definition.
I don't know yet the format which we should use (whether it should be gremlin query or some json / xml or something else).
Is there any updates regarding Schema Management?
Just to not do double work for Schema Management, I would like to know if someone was working on making DDL for schema. If so, were there any troubles? What format is better to use for schema definition?
Currently I am thinking about JSON format, something like:
[
  {
    type: vertexLabel,
    name: myVertexLabel
  },
  {
    type: edgeLabel,
    name: myEdgeLabel
    multiplicity: MANY2ONE
  },
  {
      type: propertyKey,
      dataType: String.class
      name: myProperty,
      cardinality: LIST
   },
   {
      type: compositeIndex,
      indexOnly: myVertexLabel,
      keys: [
         {
             name: myProperty
          }
      ]
   },
   {
      type: mixedIndex,
      keys: [
         {
             name: myProperty,
             parameters: [
                {
                     key: parameterKey,
                     value: parameterValue
                }
             ]
          }
      ]
    }
]

I didn't think much about schema definition, so I might miss some points. If you have any thoughts / suggestions on the format or how should this feature be implemented, it would be great. Also, I didn't work with GraphQL, so will check a little bit later if that format might be used as well.

Best regards,
Oleksandr


On Friday, February 28, 2020 at 8:30:21 PM UTC+2 fa...@... wrote:

An HTTP API would have the benefit of making the schema management available to users of the Gremlin server without the mentioned problems for making it accessible via Gremlin. As it would just expose the underlying Java API (current or a new one), it would be 

nice if the web service would be optional if JG is used embedded.


+1

One of my major concerns is to make JanusGraph more modular.

Re: [janusgraph-foundationdb] - Repository cleanup questions

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

I went ahead and created individual issues for each of the tasks in case anyone wants to jump in and help with the cleanup process:
Please let me know if you have any questions; feel free to add me as a reviewer on PRs addressing any of these issues.

Misha


On Tue, Jul 14, 2020 at 6:42 PM Misha Brukman <mbru...@...> wrote:
I support the proposal to change the package names/paths to match JanusGraph style since it was moved from Expero to the JanusGraph org. The changes I think you want to make are:
  • move directories from com/experoinc/janusgraph --> org/janusgraph
  • update package names accordingly
  • update copyright line from Expero Inc. -> JanusGraph Authors
  • create AUTHORS.txt, add Expero Inc there
  • create CONTRIBUTORS.txt, add Ted Wilmes there (and anyone else in the Git history so far, but see below for details on copyright)
What's the difference between these two and why do we need both of them?
  • AUTHORS.txt are the copyright holders aka copyright owners of the code — these are either people (if they're individuals and they own the copyright of their contributions) or companies (if they own the copyright of their employees' contributions)
  • CONTRIBUTORS.txt — these are the people that did the actual work, who don't own the copyright themselves (if they do, they're already in AUTHORS.txt)
For all of us whose companies own the copyright of our contributions to JanusGraph (as evidenced by the fact that we're on our companies' Corporate CLAs), our company name would go into AUTHORS.txt and our own name would go into CONTRIBUTORS.txt.

However, before we do any changes to the code, as a first PR, can we please add a .travis.yml file to the repo so that we start building and testing each change? Otherwise, we'll be in the situation we were in with the JanusGraph repo (before Travis CI was setup), where PR reviewers had to manually patch the PR to verify that it builds and tests pass before approving them, and that was painful. The 2 big cleanups where PR #1 and #2, and Travis CI config was only added in PR #3, and Henry Saputra was very patient in doing this manually, but let's not repeat that again. :-)

Back to the original topic: I did the initial cleanup on the JanusGraph repo after importing from thinkaurelius/titan; you can see my changes in:
Specifically, for PR #2 (which consists of 2 commits), you can see the scripts and the changes that were done in the individual commits:
Please feel free to reuse & adapt the scripts as needed for this update and include them in the commit message, as they may be useful in the future, should someone else donate another large subproject to JanusGraph!

Re: @author tags: I think we kept a bunch of them for historical reasons to give credit to the original Aurelius folks (even though we also kept the full Git history, so everyone can see who the original author was). https://github.com/JanusGraph/janusgraph/search?q=%22%40author%22 shows 607 appearances of `author@` in the codebase.

We also kept <developer> and <contributor> tags in pom.xml files, e.g., see https://github.com/JanusGraph/janusgraph/blob/c433f54e01887245f02189cceac83dafdec94514/pom.xml#L19-L46 — I don't think there's a particular need or desire to remove either @author lines or the <developer> / <contributor> tags. If we want to make a large-scale change to remove ALL of them, we should discuss this with a vote on janusgraph-dev@ but I'm not sure whether it's worth it, and as I mentioned above, we owe a lot of gratitude to the original authors of Titan from which JanusGraph came, so I would feel bad removing them all in one fell swoop.

Hope this helps!

I'm happy to help with these changes, or if you'd like to make them, I'm happy to review them.

Misha

On Tue, Jul 14, 2020 at 5:47 PM Jason Plurad <plu...@...> wrote:
I didn't work on initial fork from thinkaurelius/titan, so it'd be great if those folks chimed in on this thread.

From what I recall of that fork process, all of the author tags were removed from the source files, and the AUTHORS.txt + CONTRIBUTORS.txt were created in its place. We could go ahead and create an AUTHORS.txt and put Expero Inc in it. I don't think a CONTRIBUTORS.txt file is required. All JanusGraph contributors have to sign a CLA to contribute, and once signed, they are covered by "JanusGraph Authors" (twilmes is already covered by that also).

For copyright, I think we'd need a NOTICE.txt (https://github.com/JanusGraph/janusgraph/blob/master/NOTICE.txt) which can describe that the code was contributed by Expero Inc to JanusGraph. Then update the copyright in the source files to "JanusGraph Authors". Check out the Apache License (https://www.apache.org/licenses/LICENSE-2.0) under Redistribution of Derivative Works.

On Friday, July 10, 2020 at 5:54:50 PM UTC-4 jacks...@... wrote:
Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson

--
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/c11b7d10-7ab9-4f56-bcce-3ebdc22889acn%40googlegroups.com.
Re: [janusgraph-foundationdb] - Repository cleanup questions

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

I support the proposal to change the package names/paths to match JanusGraph style since it was moved from Expero to the JanusGraph org. The changes I think you want to make are:
  • move directories from com/experoinc/janusgraph --> org/janusgraph
  • update package names accordingly
  • update copyright line from Expero Inc. -> JanusGraph Authors
  • create AUTHORS.txt, add Expero Inc there
  • create CONTRIBUTORS.txt, add Ted Wilmes there (and anyone else in the Git history so far, but see below for details on copyright)
What's the difference between these two and why do we need both of them?
  • AUTHORS.txt are the copyright holders aka copyright owners of the code — these are either people (if they're individuals and they own the copyright of their contributions) or companies (if they own the copyright of their employees' contributions)
  • CONTRIBUTORS.txt — these are the people that did the actual work, who don't own the copyright themselves (if they do, they're already in AUTHORS.txt)
For all of us whose companies own the copyright of our contributions to JanusGraph (as evidenced by the fact that we're on our companies' Corporate CLAs), our company name would go into AUTHORS.txt and our own name would go into CONTRIBUTORS.txt.

However, before we do any changes to the code, as a first PR, can we please add a .travis.yml file to the repo so that we start building and testing each change? Otherwise, we'll be in the situation we were in with the JanusGraph repo (before Travis CI was setup), where PR reviewers had to manually patch the PR to verify that it builds and tests pass before approving them, and that was painful. The 2 big cleanups where PR #1 and #2, and Travis CI config was only added in PR #3, and Henry Saputra was very patient in doing this manually, but let's not repeat that again. :-)

Back to the original topic: I did the initial cleanup on the JanusGraph repo after importing from thinkaurelius/titan; you can see my changes in:
Specifically, for PR #2 (which consists of 2 commits), you can see the scripts and the changes that were done in the individual commits:
Please feel free to reuse & adapt the scripts as needed for this update and include them in the commit message, as they may be useful in the future, should someone else donate another large subproject to JanusGraph!

Re: @author tags: I think we kept a bunch of them for historical reasons to give credit to the original Aurelius folks (even though we also kept the full Git history, so everyone can see who the original author was). https://github.com/JanusGraph/janusgraph/search?q=%22%40author%22 shows 607 appearances of `author@` in the codebase.

We also kept <developer> and <contributor> tags in pom.xml files, e.g., see https://github.com/JanusGraph/janusgraph/blob/c433f54e01887245f02189cceac83dafdec94514/pom.xml#L19-L46 — I don't think there's a particular need or desire to remove either @author lines or the <developer> / <contributor> tags. If we want to make a large-scale change to remove ALL of them, we should discuss this with a vote on janusgraph-dev@ but I'm not sure whether it's worth it, and as I mentioned above, we owe a lot of gratitude to the original authors of Titan from which JanusGraph came, so I would feel bad removing them all in one fell swoop.

Hope this helps!

I'm happy to help with these changes, or if you'd like to make them, I'm happy to review them.

Misha

On Tue, Jul 14, 2020 at 5:47 PM Jason Plurad <plu...@...> wrote:
I didn't work on initial fork from thinkaurelius/titan, so it'd be great if those folks chimed in on this thread.

From what I recall of that fork process, all of the author tags were removed from the source files, and the AUTHORS.txt + CONTRIBUTORS.txt were created in its place. We could go ahead and create an AUTHORS.txt and put Expero Inc in it. I don't think a CONTRIBUTORS.txt file is required. All JanusGraph contributors have to sign a CLA to contribute, and once signed, they are covered by "JanusGraph Authors" (twilmes is already covered by that also).

For copyright, I think we'd need a NOTICE.txt (https://github.com/JanusGraph/janusgraph/blob/master/NOTICE.txt) which can describe that the code was contributed by Expero Inc to JanusGraph. Then update the copyright in the source files to "JanusGraph Authors". Check out the Apache License (https://www.apache.org/licenses/LICENSE-2.0) under Redistribution of Derivative Works.

On Friday, July 10, 2020 at 5:54:50 PM UTC-4 jacks...@... wrote:
Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson

--
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/c11b7d10-7ab9-4f56-bcce-3ebdc22889acn%40googlegroups.com.
Re: [janusgraph-foundationdb] - Repository cleanup questions

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

I didn't work on initial fork from thinkaurelius/titan, so it'd be great if those folks chimed in on this thread.

From what I recall of that fork process, all of the author tags were removed from the source files, and the AUTHORS.txt + CONTRIBUTORS.txt were created in its place. We could go ahead and create an AUTHORS.txt and put Expero Inc in it. I don't think a CONTRIBUTORS.txt file is required. All JanusGraph contributors have to sign a CLA to contribute, and once signed, they are covered by "JanusGraph Authors" (twilmes is already covered by that also).

For copyright, I think we'd need a NOTICE.txt (https://github.com/JanusGraph/janusgraph/blob/master/NOTICE.txt) which can describe that the code was contributed by Expero Inc to JanusGraph. Then update the copyright in the source files to "JanusGraph Authors". Check out the Apache License (https://www.apache.org/licenses/LICENSE-2.0) under Redistribution of Derivative Works.


On Friday, July 10, 2020 at 5:54:50 PM UTC-4 jacks...@... wrote:
Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson
[janusgraph-foundationdb] - Repository cleanup questions

Christopher Jackson <jackson.ch...@...>
 

Hi Folks,

I wanted to get started on making some contributions to the foundationdb adapter now that the initial repo is established, first and foremost by cleaning up the repo. IE. making it conform to the standards/conventions used by the rest of the janusgraph projects/repositories. While working on https://github.com/JanusGraph/janusgraph-foundationdb/issues/10 I also wanted to tackle other cleanup type items. In particular I'm curious to what should be done (if anything) about lines like these:
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L1
https://github.com/JanusGraph/janusgraph-foundationdb/blob/master/src/main/java/com/experoinc/janusgraph/diskstorage/foundationdb/FoundationDBConfigOptions.java#L26

Should the copyright tags and author tags still be present? And in general how do `@author` tags work in the janusgraph open source project? I know that the main repository has files:
https://github.com/JanusGraph/janusgraph/blob/master/AUTHORS.txt
https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTORS.txt
which I believe cover both these points, should we create analogous files in this repository and remove author tags and copyright statements from each individual source file?

Again I don't know what proper etiquette is in this regard so looking for input from others before making any changes.

Regards,
Christopher Jackson
Re: [janusgraph-foundationdb] initial fork options

Christopher Jackson <jackson.ch...@...>
 

Thanks Ted and Expero for contributing this code and migrating it to its new home so quickly!
Add support to AWS Keyspaces (or DynamoDB) as storage backend #2154

Nicolò Marchi <nicolo...@...>
 

Hi all, 

I'm reporting here a feature request that i added as issue on the Janusgraph github project.

Describe the feature:
Add the possibility to use AWS Keyspaces as storage backend since it is a SaaS service and compatible with Cassandra. Or add the possibility to use AWS DynamoDB as storage backend using the old connector made by AWS Labs.
These could be good feature since developers could use managed services and avoid the difficulty in manage an "important storage like Cassandra"

Describe a specific use case for the feature:
In a completely SaaS architecture is common to have DBs and other technologies provided as a service. Have the possibility to connect Janus to an already existing (for other purposes) Keyspaces cluster or DynamoDB endpoint gives the possibility to have all data in a single service.



Is it something that could be feasable? Or something that someone else could use or need?? 

What do you think about it?


Cheers, 


Nicolò
Re: [janusgraph-foundationdb] initial fork options

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

That's great to hear! Thank you to Ted & Expero for contributing your FoundationDB backend to the Janusgraph Project!


On Tue, Jun 30, 2020 at 10:54 AM Ted Wilmes <twi...@...> wrote:
Success! It is transferred over: https://github.com/JanusGraph/janusgraph-foundationdb. I'm excited to see things progress on the FDB front.

Thanks,
Ted

On Fri, Jun 26, 2020 at 2:22 PM Ted Wilmes <twi...@...> wrote:
I have approval on our side. I'll let you all know when it's been transferred over.

Thanks,
Ted

On Wed, Jun 24, 2020 at 12:40 PM Jason Plurad <plu...@...> wrote:
Thanks Ted. Chime back on this thread once you get clearance from your company, then we can move forward after the experoinc repo is transferred over.

On Saturday, June 20, 2020 at 2:42:15 AM UTC-4 Chris Jackson wrote:
My suggestion would also be either option #1 or option #4.

--
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/tleruwXYBzU/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/1bd113bc-877a-4479-93d4-4f8fa7752d4bn%40googlegroups.com.

--
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/CAGrm2%3DBq-_eo-OveMjkPBTQDF4cS83EJ-uY%3DYn%2BhEaY7tbQ-PA%40mail.gmail.com.
Expose the index backend exception when commit?

Chen Wu <cjx...@...>
 

Hi all, is there any plan to expose the index backend exception to for user handling when commit transaction since some use cases require the consisitency between the storeage backend and the index backend, and users might hope to capture these exceptions to do some actions such as rollback and retry. 
Re: [janusgraph-foundationdb] initial fork options

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

Success! It is transferred over: https://github.com/JanusGraph/janusgraph-foundationdb. I'm excited to see things progress on the FDB front.

Thanks,
Ted

On Fri, Jun 26, 2020 at 2:22 PM Ted Wilmes <twi...@...> wrote:
I have approval on our side. I'll let you all know when it's been transferred over.

Thanks,
Ted

On Wed, Jun 24, 2020 at 12:40 PM Jason Plurad <plu...@...> wrote:
Thanks Ted. Chime back on this thread once you get clearance from your company, then we can move forward after the experoinc repo is transferred over.

On Saturday, June 20, 2020 at 2:42:15 AM UTC-4 Chris Jackson wrote:
My suggestion would also be either option #1 or option #4.

--
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/tleruwXYBzU/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/1bd113bc-877a-4479-93d4-4f8fa7752d4bn%40googlegroups.com.
Re: Janusgraph functionality issue

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

Hi Shiva,

unfortunately I can't help much on the CLA front, I am basically just your fellow contributor and don't manage CLAs. If you want to chase this specific item, probably the best place is  janusgr...@... as suggested in the doc I posted the link to before.

Generally speaking, this project is supported by volunteers in their spare time, there doesn't seem to be anyone sponsored to work on it full time, so there may be any number of reasons for the delay in response to your contribution and CLA request. People could be just busy with their full-time work, or being affected by epidemic, or just having nice summer time off etc. 

Similarly, when it comes to reviewing the actual contribution, many people (me included) get involved only occasionally, if they happen to be familiar with the relevant part of the codebase, or affected by the particular issue your contribution addresses.  So it may take some time until a "more involved" team member can look at it and dig into the details.  

Having been "in your shoes" before, I understand that delays may not exactly fill you with enthusiasm, but be assured that they don't mean your contribution is not appreciated - it will get looked at, and if it does add value, it will be merged eventually.


On Tue, 30 Jun 2020 at 09:37, <shivain...@...> wrote:
Hi Dmitry,

We have submitted a pull request and it got failed in CLA process.

Our companies CLA Signatory raised a request to act as a CLA Manager from our company for this project.
But the request got stuck at 'Awaiting Approval' since last few days. (Attached screenshot for reference)

Could you please help us on this issue.

Screen Shot 2020-06-29 at 11.49.21 AM.png




On Sunday, June 14, 2020 at 12:28:30 PM UTC+5:30, Shiva Krishnan wrote:
Hi Dmitry,

 Thank you for the information.
 I will raise the PR as soon as possible.

Regards
Shiva

On Thursday, June 11, 2020 at 8:32:25 PM UTC+5:30, Dmitry Kovalev wrote:
BTW, the doc suggests that you start with signing the CLA before forking and raising pull request. In case of individual contribution this is easy and fast, but for corporate route (which I am guessing you have to go through) it can be a long and unexciting part of contribution process. 

Likewise, getting your changes to be reviewed can also take time, depending on how big and complex your change is, and how many people are familiar enough with that part of code.

So I suggest that you raise the PR as early in the process as possible, and the CLA bit can catch up (while it's still obviously required before your contribution can be finally accepted)

On Thu, 11 Jun 2020 at 11:17, Dmitry Kovalev <d...@...> wrote:
Hi Shiva,

Thanks for taking time to dive into the issue and deciding to contribute.

Please have a look at this page: https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTING.md - it describes the steps to contribute, which are pretty standard.

Thanks,
Dmitry

On Thu, 11 Jun 2020 at 10:40, <shi...@...> wrote:
Hello Everyone,

I have found the root cause for this issue and also have the fix for the same.

Please guide me if I can contribute for this project as I'm new to this community.

Thanks
Shiva

On Monday, June 8, 2020 at 6:50:04 PM UTC+5:30, Shiva Krishnan wrote:
Hi,

I have noticed a corruption in index after reindexing vertex-centric indices with direction 'IN'.

Issue : A self-link is getting added to every vertex after reindexing.

To demonstrate this, I have taken a very small graph consists of two vertices (A & B) and one edge connecting the two.
Edge Label -> link
Edge has one property key (Integer) -> assocKind

//Creating the Vertex Centrix Index
gremlin > edgeLabel = mgmt.getEdgeLabel("link");
gremlin > assocKind= mgmt.getPropertyKey("assocKind")
gremlin > mgmt.buildEdgeIndex(edgeLabel, "myVertexCentricIndex", Direction.IN, assocKind);

Please note i have given the direction IN for the index.


//Creating the Edge from A to B: (a and b are vertices)
a.addEdge("link",b,"assocKind",1)

Output Before Reindexing :
gremlin> g.V().has('name' , 'A').inE().hasLabel('link').has('assocKind',1)
//no IN edges to vertex A  Correct

gremlin> g.V().has('name' , 'A').outE().hasLabel('link').has('assocKind',1)
==>e[4e1f-b6g-1bit-1pqw][14488-link->80024]   Correct

Now I ran the reindex command
// 'index' is the vertex centric index which is created above
gremlin> m.updateIndex(index, SchemaAction.REINDEX).get()

Output After Reindexing :
gremlin> g.V().has('_objId','A').inE().hasLabel('link').has('assocKind',1)
==>e[4e1f-b6g-1bit-b6g][14488-link->14488] Wrong

gremlin> g.V().has('_objId','A').bothE().hasLabel('link').has('assocKind',1)
==>e[4e1f-b6g-1bit-1pqw][14488-link->80024]
==>e[4e1f-b6g-1bit-b6g][14488-link->14488] Unexpected Link

This issue happens in janusgraph 0.5.2 also.

Thanks
Shiva

--
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 jan...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/ea55b56a-dc8b-456e-b8c9-071de9b9f35ao%40googlegroups.com.

--
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/4db2f58b-cd2d-406e-a6bb-bfb14e91b6edo%40googlegroups.com.
Re: Janusgraph functionality issue

shivain...@...
 

Hi Dmitry,

We have submitted a pull request and it got failed in CLA process.
https://github.com/JanusGraph/janusgraph/pull/2137

Our companies CLA Signatory raised a request to act as a CLA Manager from our company for this project.
But the request got stuck at 'Awaiting Approval' since last few days. (Attached screenshot for reference)

Could you please help us on this issue.

Screen Shot 2020-06-29 at 11.49.21 AM.png




On Sunday, June 14, 2020 at 12:28:30 PM UTC+5:30, Shiva Krishnan wrote:
Hi Dmitry,

 Thank you for the information.
 I will raise the PR as soon as possible.

Regards
Shiva

On Thursday, June 11, 2020 at 8:32:25 PM UTC+5:30, Dmitry Kovalev wrote:
BTW, the doc suggests that you start with signing the CLA before forking and raising pull request. In case of individual contribution this is easy and fast, but for corporate route (which I am guessing you have to go through) it can be a long and unexciting part of contribution process. 

Likewise, getting your changes to be reviewed can also take time, depending on how big and complex your change is, and how many people are familiar enough with that part of code.

So I suggest that you raise the PR as early in the process as possible, and the CLA bit can catch up (while it's still obviously required before your contribution can be finally accepted)

On Thu, 11 Jun 2020 at 11:17, Dmitry Kovalev <d...@...> wrote:
Hi Shiva,

Thanks for taking time to dive into the issue and deciding to contribute.

Please have a look at this page: https://github.com/JanusGraph/janusgraph/blob/master/CONTRIBUTING.md - it describes the steps to contribute, which are pretty standard.

Thanks,
Dmitry

On Thu, 11 Jun 2020 at 10:40, <shi...@...> wrote:
Hello Everyone,

I have found the root cause for this issue and also have the fix for the same.

Please guide me if I can contribute for this project as I'm new to this community.

Thanks
Shiva

On Monday, June 8, 2020 at 6:50:04 PM UTC+5:30, Shiva Krishnan wrote:
Hi,

I have noticed a corruption in index after reindexing vertex-centric indices with direction 'IN'.

Issue : A self-link is getting added to every vertex after reindexing.

To demonstrate this, I have taken a very small graph consists of two vertices (A & B) and one edge connecting the two.
Edge Label -> link
Edge has one property key (Integer) -> assocKind

//Creating the Vertex Centrix Index
gremlin > edgeLabel = mgmt.getEdgeLabel("link");
gremlin > assocKind= mgmt.getPropertyKey("assocKind")
gremlin > mgmt.buildEdgeIndex(edgeLabel, "myVertexCentricIndex", Direction.IN, assocKind);

Please note i have given the direction IN for the index.


//Creating the Edge from A to B: (a and b are vertices)
a.addEdge("link",b,"assocKind",1)

Output Before Reindexing :
gremlin> g.V().has('name' , 'A').inE().hasLabel('link').has('assocKind',1)
//no IN edges to vertex A  Correct

gremlin> g.V().has('name' , 'A').outE().hasLabel('link').has('assocKind',1)
==>e[4e1f-b6g-1bit-1pqw][14488-link->80024]   Correct

Now I ran the reindex command
// 'index' is the vertex centric index which is created above
gremlin> m.updateIndex(index, SchemaAction.REINDEX).get()

Output After Reindexing :
gremlin> g.V().has('_objId','A').inE().hasLabel('link').has('assocKind',1)
==>e[4e1f-b6g-1bit-b6g][14488-link->14488] Wrong

gremlin> g.V().has('_objId','A').bothE().hasLabel('link').has('assocKind',1)
==>e[4e1f-b6g-1bit-1pqw][14488-link->80024]
==>e[4e1f-b6g-1bit-b6g][14488-link->14488] Unexpected Link

This issue happens in janusgraph 0.5.2 also.

Thanks
Shiva

--
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 jan...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/ea55b56a-dc8b-456e-b8c9-071de9b9f35ao%40googlegroups.com.
Re: [janusgraph-foundationdb] initial fork options

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

I have approval on our side. I'll let you all know when it's been transferred over.

Thanks,
Ted

On Wed, Jun 24, 2020 at 12:40 PM Jason Plurad <plu...@...> wrote:
Thanks Ted. Chime back on this thread once you get clearance from your company, then we can move forward after the experoinc repo is transferred over.

On Saturday, June 20, 2020 at 2:42:15 AM UTC-4 Chris Jackson wrote:
My suggestion would also be either option #1 or option #4.

--
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/tleruwXYBzU/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/1bd113bc-877a-4479-93d4-4f8fa7752d4bn%40googlegroups.com.
Re: [janusgraph-foundationdb] initial fork options

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

Thanks Ted. Chime back on this thread once you get clearance from your company, then we can move forward after the experoinc repo is transferred over.


On Saturday, June 20, 2020 at 2:42:15 AM UTC-4 Chris Jackson wrote:
My suggestion would also be either option #1 or option #4.
Re: [janusgraph-foundationdb] initial fork options

Christopher Jackson <jackson.ch...@...>
 

My suggestion would also be either option #1 or option #4.
Re: [janusgraph-foundationdb] initial fork options

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

Four makes good sense to me. I don't think that'll be an issue on our end but will confirm.

--Ted
Re: [janusgraph-foundationdb] initial fork options

f.gri...@...
 

Of course from my point of view, the easiest option is #2, taking my repo (rngcntr/janusgraph-foundationdb) as the base ;)
But to be honest, I don't think this is the cleanest way to go. I developed most of this alone and without review of others. Furthermore, I refactored much of the existing code. I can't speak for the other authors, but I think the situation might be similar for them.

So my suggestion would be to go for #1 or even better #4 as suggested by Misha.
181 - 200 of 1602