Date   

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.


Re: [janusgraph-foundationdb] initial fork options

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

I'd like to propose another option:

4. Ask Ted & Expero if they wouldn't mind transferring the initial repo experoinf/janusgraph-foundationdb into the JanusGraph org as-is so it becomes the authoritative home (rather than forking it), and then each of the existing fork owners can propose PRs to merge their changes incrementally into the new base repo.

On Tue, Jun 16, 2020 at 10:14 AM Jason Plurad <plu...@...> wrote:
For the new janusgraph-foundationdb repo, we need a starting point. Here are a few options:

1. Fork from experoinc/janusgraph-foundationdb into JanusGraph/janusgraph-foundationdb. The external fork authors submit PRs with their changes to the new repo, and the code changes will be reviewed before commit.

2. Fork from one of the external janusgraph-foundationdb forks into JanusGraph/janusgraph-foundationdb. rngcntr/janusgraph-foundationdb has the most commits among the three. The other two forks would submit PRs to the new repo.

3. Have the 3 authors merge their forks first, then fork the unified fork into JanusGraph/janusgraph-foundationdb. This could provide a unified repo before imposing code review process.

I haven't reviewed any of the code out there, so I don't have a strong opinion on any of these options. Open for more ideas or suggestions from the authors, committers, and others in the community.

-- Jason

--
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/ed630d2d-cf9d-44ab-85d4-27042208e932o%40googlegroups.com.


[janusgraph-foundationdb] initial fork options

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

For the new janusgraph-foundationdb repo, we need a starting point. Here are a few options:

1. Fork from experoinc/janusgraph-foundationdb into JanusGraph/janusgraph-foundationdb. The external fork authors submit PRs with their changes to the new repo, and the code changes will be reviewed before commit.

2. Fork from one of the external janusgraph-foundationdb forks into JanusGraph/janusgraph-foundationdb. rngcntr/janusgraph-foundationdb has the most commits among the three. The other two forks would submit PRs to the new repo.

3. Have the 3 authors merge their forks first, then fork the unified fork into JanusGraph/janusgraph-foundationdb. This could provide a unified repo before imposing code review process.

I haven't reviewed any of the code out there, so I don't have a strong opinion on any of these options. Open for more ideas or suggestions from the authors, committers, and others in the community.

-- Jason


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

Great to see lots of support from the community on this. I'll start another thread for next steps to initiate the new repo.


On Friday, June 12, 2020 at 6:08:54 PM UTC-4, Anshul Pathak wrote:
 +1 

On Jun 11, 2020, at 7:32 AM, Jason Plurad <pluradj> wrote:

Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason

--
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 janusgraph-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-dev/4009696c-98b9-4a04-ad21-eb0572425de7o%40googlegroups.com.


Re: Janusgraph functionality issue

shivain...@...
 

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


Re: v0.5.2 inmemory storage backend via Java

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

Hi

 We moved the inmemory component in their own project called janusgraph-inmemory. 
Probably we should update the upgrade instructions for JanusGraph 0.5.


Greetings
Jan

On 13. Jun 2020, at 00:14, ryss...@... wrote:


it seems there is an issue with the java code in version 0.5.2 causing me to be unable to use a storage.backend=inmemory as a config for my testing.
using in memory backend via gremlin-server.sh works just fine.
I dug a little deeper and it seems in the java code there is a StandardStoremanager class which tells the janusgraph factory where to find the implementation class for whatever storage backend the user provided. For in memory it tells the factory to find the implementation at "org.janusgraph.diskstorage.inmemory.InMemoryStoreManager" but that class cannot be found in the code (class not found error and I cant find it myself in github or on the javadocs). That class exists in older versions of the code. 
If this is a bug Im really surprised Im not seeing more people ask about it which makes me think I am probably doing something wrong. Please help if you can.

--
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/c8231c16-5e33-4821-bec8-bf02be163944o%40googlegroups.com.


Re: Official support for FoundationDB?

Anshul Pathak <anshul...@...>
 

+1 , we are also planning to use FDB and this will surely help


On Friday, 22 May 2020 12:08:42 UTC-7, jack...@... wrote:
Hi everyone,

Seems there may be a good deal of interest in having support for FoundationDB as a backend storage for Janusgraph. Ted Wilmes had created a storage adapter https://github.com/experoinc/janusgraph-foundationdb that hasn't seen any updates by Ted for some time, however other teams have picked up where Ted left off with a few forks seeing some activity:


I wanted to start a conversation about working towards getting this adapter added as part of the main janusgraph code base and making FDB an officially supported backend.

Personally, I am interested in seeing this happen as I work for IBM and we are planning on using Janusgraph on top of FoundationDB for a few projects. The https://github.com/blindenvy/janusgraph-foundationdb fork is where some of our team members have started to make changes. We originally forked from experoinc repo and only noticed the other forks after the fact. It seems both the rngcntr and skyrocknroll forks have seen a good deal of changes and may be better forks to choose as a starting point to bring in to the official code base.  

If the community decides they want to do this I would like to offer my assistance in helping bring the code in and adding documentation to jump start the process. 

I look forward to hearing everyones thoughts on this topic. 

Regards,
Christopher Jackson


Re: [PROPOSAL] new repository for janusgraph-foundationdb

Anshul Pathak <anshul...@...>
 

 +1 

On Jun 11, 2020, at 7:32 AM, Jason Plurad <plu...@...> wrote:

Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason

--
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/4009696c-98b9-4a04-ad21-eb0572425de7o%40googlegroups.com.


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

+1


On Thursday, June 11, 2020 at 10:32:37 AM UTC-4, Jason Plurad wrote:
Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

Vote: +1


On Thu, Jun 11, 2020 at 10:32 AM Jason Plurad <plu...@...> wrote:
Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason

--
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/4009696c-98b9-4a04-ad21-eb0572425de7o%40googlegroups.com.


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

+1

Great to see progress with the FDB backend.

Am Freitag, 12. Juni 2020 08:44:46 UTC+2 schrieb Jan Jansen:

My vote: +1

Greetings,
Jan

On Thursday, June 11, 2020 at 4:32:37 PM UTC+2, Jason Plurad wrote:
Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

My vote: +1

Greetings,
Jan

On Thursday, June 11, 2020 at 4:32:37 PM UTC+2, Jason Plurad wrote:
Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason


Violation of UNIQUE INDEX deleted the property from the all the all ready existed vertex

krishna...@...
 

Hi,

i have created a Unique Composite Index for vertices with id, name properties.
  1. create a vertex with an id(-109), name("test").
  2. take the already created vertex which is having different id(-201654672484678624),name('test") which are having few properties like age, createdTime, gender, etc
  3. try to update the already available vertex stated in point 2 with id(-109) of vertex stated in point 1
  4. then the following exception is thrown which is expected
    1. Adding this property for key [id] and value [-109] violates a uniqueness constraint [newUniqueIndex]Type ':help' or ':h' for help.Display stack trace? [yN]yorg.janusgraph.core.SchemaViolationException: Adding this property for key [id] and value [-109] violates a uniqueness constraint [newUniqueIndex]{{ at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.addProperty(StandardJanusGraphTx.java:817)}}{{ at org.janusgraph.graphdb.transaction.StandardJanusGraphTx.addProperty(StandardJanusGraphTx.java:745)}}{{ at org.janusgraph.graphdb.vertices.AbstractVertex.property(AbstractVertex.java:152)}}{{ at org.janusgraph.core.JanusGraphVertex.property(JanusGraphVertex.java:72)}}{{ at org.janusgraph.core.JanusGraphVertex.property(JanusGraphVertex.java:33}}{{}}
  5. But the unexpected thing happening is the id(-201654672484678624) property of the vertex stated in point is removed from it
Note: i am using cassandra as backend and ES for indexing

can you please help me to solve the issue as there is a loss in data as we can't retrive the data which is lost.


attaching the console logs of reproducing the issue through gremlin console


Thanks
Krishna Jalla


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

Hey guys, been out of office so catching up on this. Excited to see the FDB interest.

Vote: +1

Thanks,
Ted


Official support for FoundationDB?

Lakshay Rastogi <lakshay1...@...>
 

I would like to offer my assistance and get involved too!


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

absolutely: +1

rafa


On Thursday, June 11, 2020 at 10:35:57 AM UTC-4, Oleksandr Porunov wrote:
My vote: +1

Best regards,
Oleksandr

On Thursday, June 11, 2020 at 5:32:37 PM UTC+3, Jason Plurad wrote:
Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason


Re: Janusgraph functionality issue

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

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


Re: [PROPOSAL] new repository for janusgraph-foundationdb

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

My vote: +1

Best regards,
Oleksandr

On Thursday, June 11, 2020 at 5:32:37 PM UTC+3, Jason Plurad wrote:
Several developers from the community have expressed interest in collaborating on a storage backend for FoundationDB. As discussed on this thread, they each have a separate fork (no license changes) from the original experoinc/janusgraph-foundationdb repo that Ted Wilmes created (no updates in ~2 years).

I propose that we create a new project janusgraph-foundationdb under the JanusGraph org so that developers can work together to merge their forks and move forward.

Let's give it 72 hours for lazy consensus.

I'm +1 for this proposal.

-- Jason

181 - 200 of 1585