Date   

Re: [DISCUSS] Accept money contributions

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

Hi Misha,

Thank you for clarification!

I thought about making a collaborative group of TSC members which control funds expenses.

The expenses would be seen publicly. Something like:
https://opencollective.com/typeorm

Commission of opencollective is either 5% or 10% depending if we will control legal stuff by ourself or not.

I will hold off while we are investigating the legal stuff.

If The Linux Foundation already has paid account with Travis CI which includes more builds and we can take advantage of them then it would be great. Do you know where can we ask it?
Also, I am not familiar with this open source structure. I see that The Linux Foundation takes 9% of the raised funds when the project starts to collect funds. If so, can we expect to be funded by The Linux Foundation while we are not raising money (i.e. funded just for the Travis CI plan for now) or it doesn't work that way?
Did The Linux Foundation fund JanusGraph or did it make contributions to it before?

I am just not familiar with this relationship. All I know is that JanusGraph is under The Linux Foundation but no more details.

Best regards,
Oleksandr Porunov 


On Friday, August 16, 2019 at 11:56:56 PM UTC+3, Misha Brukman wrote:
Hi Oleksandr,

Before you start accepting money on behalf of JanusGraph, please keep in mind that The Linux Foundation did not expect us to do so when the project was started, and a fraction of the donations would need to be provided to The Linux Foundation. For details, please see section "6. Budget and Funding", paragraph (c) in https://github.com/JanusGraph/legal/blob/master/JanusGraph_Project_Charter.pdf which says:

Initially, the Project will not raise any funds and will be supported on a volunteer
basis by the Project participants. In the event the Project does decide to solicit
funding or more than one Project participant provides funding, a General &
Administrative (G&A) fee will be applied by The Linux Foundation to any funds
raised by the Project. The G&A fee shall equal 9% of the Project’s first
$1,000,000 of gross receipts each year and 6% of the Project’s gross receipts over
$1,000,000 each year. For the purposes of clarity, contributions to the Project of
IP, personnel, time, and infrastructure are not subject to the G&A fee.

So at the very least, we would need to formally notify The Linux Foundation of the intent to raise funds, which brings up all sorts of questions:
  • do we need to create a bank account for JanusGraph? Or will The Linux Foundation accept money on behalf of the project (since they are registered non-profit 501(c)(3) in the US), deduct appropriate percentages, and deposit into a JanusGraph "virtual" account?
  • does Linux Foundation already have a paid account with Travis CI which includes more builds that JanusGraph can take advantage of?
That said, since the whole purpose of these donations is to increase the amount of build workers, perhaps the currently-beta-soon-to-be-GA GitHub CI service would do the trick? Disclaimer: I haven't tried it out, and haven't done enough investigation to see whether it actually has more parallelism than Travis CI, and whether it would be able to support the large CI build matrix that JanusGraph has.
Best,
Misha

On Fri, Aug 16, 2019 at 4:42 PM Oleksandr Porunov <ale...@...> wrote:
Due to inactivity of the discussion, I am going to make actions by my own and register necessary accounts for JanusGraph.

If anyone has opposite opinion, please write it in this thread.

I think, that a paid Travis plan would help us with:
1) Run tests faster due to a bigger amount of concurrent  jobs. Sometimes where several PRs are committed it takes days to Travis to finish building.
2) Run long running jobs. We don't currently run TinkerPop tests regularly because they are too long (~8 hours) to be executed by Travis. It makes a process of TinkerPop upgrading much harder.

Travis plans are listed here:
https://travis-ci.com/plans

Currently, the plan which has the same amount of concurrent jobs as the free plan (5) is "Small Business" plan. If we buy it, than the pros is that we will be able to run long running jobs.

If we buy "Premium" plan, we will have 10 concurrent jobs and long running and possibility to execute long running jobs.

Best regards,
Oleksandr Porunov


On Tuesday, July 2, 2019 at 7:14:54 PM UTC+3, Oleksandr Porunov wrote:
Hello,

I didn't research much, but I think we could try to enable some platform which will work to collect money contributions which we can spent on some expenses. I didn't research much how it works but I think we could use the contributed money for something like:
- Buy commercial Travis plan to be able to run TinkerPop tests clearly https://travis-ci.com/plans
- Hiring a full-time developer / developers to the project
- Tickets to conferences to present JanusGraph

It is just a simple ideas. I didn't research deep but the platforms we could look at are: 
- possibly some other platforms

What the community think about this step? Do you think it could be useful?

Best regards,
Oleksandr Porunov

--
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/8fbb3281-c05e-4e30-a743-66e64a5af48f%40googlegroups.com.


Re: [DISCUSS] Accept money contributions

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

Hi Oleksandr,

Before you start accepting money on behalf of JanusGraph, please keep in mind that The Linux Foundation did not expect us to do so when the project was started, and a fraction of the donations would need to be provided to The Linux Foundation. For details, please see section "6. Budget and Funding", paragraph (c) in https://github.com/JanusGraph/legal/blob/master/JanusGraph_Project_Charter.pdf which says:

Initially, the Project will not raise any funds and will be supported on a volunteer
basis by the Project participants. In the event the Project does decide to solicit
funding or more than one Project participant provides funding, a General &
Administrative (G&A) fee will be applied by The Linux Foundation to any funds
raised by the Project. The G&A fee shall equal 9% of the Project’s first
$1,000,000 of gross receipts each year and 6% of the Project’s gross receipts over
$1,000,000 each year. For the purposes of clarity, contributions to the Project of
IP, personnel, time, and infrastructure are not subject to the G&A fee.

So at the very least, we would need to formally notify The Linux Foundation of the intent to raise funds, which brings up all sorts of questions:
  • do we need to create a bank account for JanusGraph? Or will The Linux Foundation accept money on behalf of the project (since they are registered non-profit 501(c)(3) in the US), deduct appropriate percentages, and deposit into a JanusGraph "virtual" account?
  • does Linux Foundation already have a paid account with Travis CI which includes more builds that JanusGraph can take advantage of?
That said, since the whole purpose of these donations is to increase the amount of build workers, perhaps the currently-beta-soon-to-be-GA GitHub CI service would do the trick? Disclaimer: I haven't tried it out, and haven't done enough investigation to see whether it actually has more parallelism than Travis CI, and whether it would be able to support the large CI build matrix that JanusGraph has.
Best,
Misha

On Fri, Aug 16, 2019 at 4:42 PM Oleksandr Porunov <alexand...@...> wrote:
Due to inactivity of the discussion, I am going to make actions by my own and register necessary accounts for JanusGraph.

If anyone has opposite opinion, please write it in this thread.

I think, that a paid Travis plan would help us with:
1) Run tests faster due to a bigger amount of concurrent  jobs. Sometimes where several PRs are committed it takes days to Travis to finish building.
2) Run long running jobs. We don't currently run TinkerPop tests regularly because they are too long (~8 hours) to be executed by Travis. It makes a process of TinkerPop upgrading much harder.

Travis plans are listed here:
https://travis-ci.com/plans

Currently, the plan which has the same amount of concurrent jobs as the free plan (5) is "Small Business" plan. If we buy it, than the pros is that we will be able to run long running jobs.

If we buy "Premium" plan, we will have 10 concurrent jobs and long running and possibility to execute long running jobs.

Best regards,
Oleksandr Porunov


On Tuesday, July 2, 2019 at 7:14:54 PM UTC+3, Oleksandr Porunov wrote:
Hello,

I didn't research much, but I think we could try to enable some platform which will work to collect money contributions which we can spent on some expenses. I didn't research much how it works but I think we could use the contributed money for something like:
- Buy commercial Travis plan to be able to run TinkerPop tests clearly https://travis-ci.com/plans
- Hiring a full-time developer / developers to the project
- Tickets to conferences to present JanusGraph

It is just a simple ideas. I didn't research deep but the platforms we could look at are: 
- possibly some other platforms

What the community think about this step? Do you think it could be useful?

Best regards,
Oleksandr Porunov

--
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/8fbb3281-c05e-4e30-a743-66e64a5af48f%40googlegroups.com.


Re: [DISCUSS] Accept money contributions

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

Due to inactivity of the discussion, I am going to make actions by my own and register necessary accounts for JanusGraph.

If anyone has opposite opinion, please write it in this thread.

I think, that a paid Travis plan would help us with:
1) Run tests faster due to a bigger amount of concurrent  jobs. Sometimes where several PRs are committed it takes days to Travis to finish building.
2) Run long running jobs. We don't currently run TinkerPop tests regularly because they are too long (~8 hours) to be executed by Travis. It makes a process of TinkerPop upgrading much harder.

Travis plans are listed here:
https://travis-ci.com/plans

Currently, the plan which has the same amount of concurrent jobs as the free plan (5) is "Small Business" plan. If we buy it, than the pros is that we will be able to run long running jobs.

If we buy "Premium" plan, we will have 10 concurrent jobs and long running and possibility to execute long running jobs.

Best regards,
Oleksandr Porunov


On Tuesday, July 2, 2019 at 7:14:54 PM UTC+3, Oleksandr Porunov wrote:
Hello,

I didn't research much, but I think we could try to enable some platform which will work to collect money contributions which we can spent on some expenses. I didn't research much how it works but I think we could use the contributed money for something like:
- Buy commercial Travis plan to be able to run TinkerPop tests clearly https://travis-ci.com/plans
- Hiring a full-time developer / developers to the project
- Tickets to conferences to present JanusGraph

It is just a simple ideas. I didn't research deep but the platforms we could look at are: 
- possibly some other platforms

What the community think about this step? Do you think it could be useful?

Best regards,
Oleksandr Porunov


Re: Replacing EntryList by an iterable type

Hieu Nguyen <ntrh...@...>
 

I have the first version working. However, with a query like this:

g.V().has("PropA", "xxx").inE().outV().out().limit(50).valueMap(true).toList(), or
g.V().has("PropA", "xxx").inE().outV().as("a").out().as("b").limit(50).path().from("a").to("b")

the steps valueMap(true) and path() are still being executed sequentially (i.e., with the 50 results of the previous steps, for each vertex JanusGraph issues one getSlice().

I expected getSlices() should also be used here, but unfortunately it doesn't.

Is my understanding correct? Is it an issue?


On Sunday, July 28, 2019 at 7:11:22 PM UTC-7, Jerry He wrote:
Hi, Hieu

I am not aware of any special reason it is such way as you point out. Feel free to propose any improvement or new design.  
The thing I can think of is that you probably would need to maintain a mini cache and mini batch (going to the backend storage) to feed into the Iterator.

Thanks.

Jerry

Thanks.

Jerry

On Fri, Jul 26, 2019 at 11:24 AM Hieu Nguyen <nt...@...> wrote:
When I look at the OrderedKeyValueStoreAdapter class, in methods getSlice() or getSlices(), objects of type RecordIterator<KeyValueEntry>  are converted to objects of type EntryList (StaticArrayEntryList). This, basically, breaks the iterator fashion since all data are collected and materialized. In many cases, this is very inefficient. For example, with multi-query enabled and I want to do g.V().has("name", "xxx").out().limit(50) and assume g.V().has("name", "xxx") result has 1k vertices, out() would trigger 1k concurrent requests and may return thousands of vertices although it is likely that with much fewer requests it can satisfy the limit(50). 

With an iterator fashion, it may try to do next() until it reaches the limit (50) and then stops.

I believe replacing EntryList by an iterable type to enable fully iterator-way of retrieving and processing data will benefit JanusGraph efficiency. My question is is there some reasons that EntryList was designed at the first place or there are some fundamental drawbacks of using iterator instead of EntryList? This would save time a lot since I plan to spend my effort to improve this.

--
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/1d6bd615-d355-4618-9a7e-5a3a687939ef%40googlegroups.com.


Re: JanusGraph - OLAP - YARN (Hadoop 3.x)

sha...@...
 

Hey, check if you have spark-unsafe.jar in your classpath. 


Re: New committer: Pavel Ershov

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

Congrats, Pavel! Thank you very much for your contributions!


On Tue, Aug 6, 2019 at 9:02 AM Florian Hockmann <f...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Pavel Ershov has been a solid contributor. He already made a significant number of contributions, including many bug fixes, but also performance improvements and improvements for the Lucene backend to get it on par with Elasticsearch and Solr.


Congratulations, Pavel!

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/010d01d54c57%2440887c90%24c19975b0%24%40florian-hockmann.de.


Re: New TSC member: Oleksandr Porunov

Jerry He <jerr...@...>
 

Congrats, Oleksandr! 

Jerry


On Tue, Aug 6, 2019 at 9:17 AM 'Misha Brukman' via JanusGraph developers <janusgr...@...> wrote:
Congratulations, Oleksandr! Thank you for your extensive contributions to JanusGraph and welcome to the TSC!

On Tue, Aug 6, 2019 at 5:26 AM Florian Hockmann <f...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new Technical Steering Committee member on the project!

Oleksandr Porunov is one of the most active contributors on JanusGraph and he already managed the 0.3.2 release. Being a TSC member enables assistance with the project management and to guide the direction of the project.

Congratulations, Oleksandr!

--
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/00fd01d54c38%24fbb30270%24f3190750%24%40florian-hockmann.de.

--
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/CANgM2oM7VUOiFoXBqnc1nd5TQr3WVby%2B5PuUtnGs%3D2D-WgGQkg%40mail.gmail.com.


Re: New committer: Pavel Ershov

Jerry He <jerr...@...>
 

Congrats Pavel!

Jerry


On Tue, Aug 6, 2019 at 7:55 AM Abhay Pandit <abha...@...> wrote:
That's great!!
Congrats Pavel



On Tue, 6 Aug 2019 at 18:32, Florian Hockmann <f...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Pavel Ershov has been a solid contributor. He already made a significant number of contributions, including many bug fixes, but also performance improvements and improvements for the Lucene backend to get it on par with Elasticsearch and Solr.


Congratulations, Pavel!

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/010d01d54c57%2440887c90%24c19975b0%24%40florian-hockmann.de.

--
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/CACCfsEbDug90xqd_Ni__acbiFo40n_7d9kqt2CxtxSOPFxNg5Q%40mail.gmail.com.


Re: Support for Partitioned Vertices in JanusGraphHadoop for OLAP queries

kestin...@...
 

Thanks for your reply, I'm currently weighing the option of simply bucketing by time vs. partitioning and then implementing partitioned vertex support in OLAP. We are using an HBase backend via Bigtable so partitioning would help prevent supernodes from overrunning the Bigtable row size limits.


On Monday, August 5, 2019 at 4:10:02 AM UTC-7, Florian Hockmann wrote:
I'm not aware of anyone working on this right now, but supernodes are definitely a big problem for graph databases, including JanusGraph, so any improvements in that area would be a great help for many users.
Regarding graph partitioning as a countermeasure for supernodes, I just want to point out that it depends on the size of your cluster of storage backend nodes how much it helps. This blog post by Ted Wilmes explains in greater detail. It talks about DSE Graph, but the same basically applies to JanusGraph.
So, you might need to implement something yourself to work around the supernode problem, like some bucketing approach where you split your supernodes up. If you want more information about supernodes and the impact they have on JanusGraph, we had a thread a while back on janusgraph-users on that topic.

Am Freitag, 2. August 2019 19:48:25 UTC+2 schrieb kes...@...:
Hey there,

I have been working with JanusGraph recently and unfortunately the dataset that I am dealing with is susceptible to supernodes (10+ mil edges into a single vertex). It seems that partitioning vertices with a particular vertex labels is the way to distribute these dense vertices in the storage backend: https://docs.janusgraph.org/latest/graph-partitioning.html but I see that these partitioned vertices must be filtered out for OLAP queries: https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-hadoop-parent/janusgraph-hadoop-core/src/main/java/org/janusgraph/hadoop/config/JanusGraphHadoopConfiguration.java#L51-L57

Are there any plans to remove this restriction anytime soon/is there anyone currently working on this problem? 

Thanks,

Joseph


Re: New TSC member: Oleksandr Porunov

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

Congratulations, Oleksandr! Thank you for your extensive contributions to JanusGraph and welcome to the TSC!


On Tue, Aug 6, 2019 at 5:26 AM Florian Hockmann <f...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new Technical Steering Committee member on the project!

Oleksandr Porunov is one of the most active contributors on JanusGraph and he already managed the 0.3.2 release. Being a TSC member enables assistance with the project management and to guide the direction of the project.

Congratulations, Oleksandr!

--
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/00fd01d54c38%24fbb30270%24f3190750%24%40florian-hockmann.de.


Re: New TSC member: Oleksandr Porunov

Abhay Pandit <abha...@...>
 

Congratulations, Oleksandr!

Thanks,
Abhay

On Tue, 6 Aug 2019 at 14:56, Florian Hockmann <f...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new Technical Steering Committee member on the project!

Oleksandr Porunov is one of the most active contributors on JanusGraph and he already managed the 0.3.2 release. Being a TSC member enables assistance with the project management and to guide the direction of the project.

Congratulations, Oleksandr!

--
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/00fd01d54c38%24fbb30270%24f3190750%24%40florian-hockmann.de.


Re: New committer: Pavel Ershov

Abhay Pandit <abha...@...>
 

That's great!!
Congrats Pavel



On Tue, 6 Aug 2019 at 18:32, Florian Hockmann <f...@...> wrote:

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Pavel Ershov has been a solid contributor. He already made a significant number of contributions, including many bug fixes, but also performance improvements and improvements for the Lucene backend to get it on par with Elasticsearch and Solr.


Congratulations, Pavel!

--
You received this message because you are subscribed to the Google Groups "JanusGraph users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to janusgra...@....
To view this discussion on the web visit https://groups.google.com/d/msgid/janusgraph-users/010d01d54c57%2440887c90%24c19975b0%24%40florian-hockmann.de.


New committer: Pavel Ershov

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

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new committer on the project!

Pavel Ershov has been a solid contributor. He already made a significant number of contributions, including many bug fixes, but also performance improvements and improvements for the Lucene backend to get it on par with Elasticsearch and Solr.


Congratulations, Pavel!


New TSC member: Oleksandr Porunov

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

On behalf of the JanusGraph Technical Steering Committee (TSC), I'm pleased to welcome a new Technical Steering Committee member on the project!

Oleksandr Porunov is one of the most active contributors on JanusGraph and he already managed the 0.3.2 release. Being a TSC member enables assistance with the project management and to guide the direction of the project.

Congratulations, Oleksandr!


Re: [MEETUP] JanusGraph Community Online Meetup August 7

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

Hello,
Meetup #2 is almost here! If you haven't signed up already but are still interested, the link can be found here: https://training.experoinc.com/janus-meetup-august7/. We're looking forward to another great set of talks and community discussion. Hope to see you all there.

Thanks,
Ted

On Fri, Jul 19, 2019 at 11:26 AM Ted Wilmes <twi...@...> wrote:
Hello,
I would like to announce the second online JanusGraph community meetup. We have a great lineup of sessions that will be given by JanusGraph community members and lots of time for interactive Q&A. Session details and signup information can be found here: https://training.experoinc.com/janus-meetup-august7/

Thanks,
Ted


Re: Support for Partitioned Vertices in JanusGraphHadoop for OLAP queries

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

I'm not aware of anyone working on this right now, but supernodes are definitely a big problem for graph databases, including JanusGraph, so any improvements in that area would be a great help for many users.
Regarding graph partitioning as a countermeasure for supernodes, I just want to point out that it depends on the size of your cluster of storage backend nodes how much it helps. This blog post by Ted Wilmes explains in greater detail. It talks about DSE Graph, but the same basically applies to JanusGraph.
So, you might need to implement something yourself to work around the supernode problem, like some bucketing approach where you split your supernodes up. If you want more information about supernodes and the impact they have on JanusGraph, we had a thread a while back on janusgraph-users on that topic.

Am Freitag, 2. August 2019 19:48:25 UTC+2 schrieb kes...@...:

Hey there,

I have been working with JanusGraph recently and unfortunately the dataset that I am dealing with is susceptible to supernodes (10+ mil edges into a single vertex). It seems that partitioning vertices with a particular vertex labels is the way to distribute these dense vertices in the storage backend: https://docs.janusgraph.org/latest/graph-partitioning.html but I see that these partitioned vertices must be filtered out for OLAP queries: https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-hadoop-parent/janusgraph-hadoop-core/src/main/java/org/janusgraph/hadoop/config/JanusGraphHadoopConfiguration.java#L51-L57

Are there any plans to remove this restriction anytime soon/is there anyone currently working on this problem? 

Thanks,

Joseph


Support for Partitioned Vertices in JanusGraphHadoop for OLAP queries

kestin...@...
 

Hey there,

I have been working with JanusGraph recently and unfortunately the dataset that I am dealing with is susceptible to supernodes (10+ mil edges into a single vertex). It seems that partitioning vertices with a particular vertex labels is the way to distribute these dense vertices in the storage backend: https://docs.janusgraph.org/latest/graph-partitioning.html but I see that these partitioned vertices must be filtered out for OLAP queries: https://github.com/JanusGraph/janusgraph/blob/master/janusgraph-hadoop-parent/janusgraph-hadoop-core/src/main/java/org/janusgraph/hadoop/config/JanusGraphHadoopConfiguration.java#L51-L57

Are there any plans to remove this restriction anytime soon/is there anyone currently working on this problem? 

Thanks,

Joseph


Re: Not able to 'addEdge' to 'CacheVertex'

bodd...@...
 

Teena:

How do you fix this problem? I'm boring about it.


On Friday, June 30, 2017 at 12:43:27 PM UTC+8, Teena K wrote:
    
    JanusGraph graph = JanusGraphFactory.open("<path>/janusgraph/conf/janusgraph-cassandra.properties");
    JanusGraphTransaction tx = graph.newTransaction();    
    GraphTraversalSource g = graph.traversal();

    <code to add vertices and edges>

    tx.commit();

    The transaction is committed after all the code is executed.

On Thursday, June 29, 2017 at 10:04:20 PM UTC+5:30, Jason Plurad wrote:
You've left out some context here. How are g` and `tx` initialized? Where is the transaction committed?

On Thursday, June 29, 2017 at 10:33:49 AM UTC-4, Teena K wrote:


down votefavorite

I have the below code in my java program that queries janusgraph to create vertices and edges if they don't exist already.

Vertex v1 = g.V().has(<key1>,<value1>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label1>,<key1>,<value1>));
Vertex v2 = g.V().has(<key2>,<value2>).tryNext().orElseGet(()->
tx.addVertex(T.label,<label2>,<key2>,<value2>));

Vertices v1 and v2 get created if they don't exist.

..code to check if an edge exists between the two vertices..
..if there is no edge between the two, create an edge
v1.addEdge(<label3>,v2,<key3>,<value3>)

If the vertices are newly created, the code works fine and the edge also gets created between the two vertices. But if the vertices already exist in the DB, the edge doesn't get created. The difference I could find between the two cases is that v1 and v2 are of 'StandardVertex' type when they are newly created and they are of 'CacheVertex' type when they already exist. 'addEdge' is a valid method in both cases. Yet the edge doesn't get created.


Re: Replacing EntryList by an iterable type

Jerry He <jerr...@...>
 

Hi, Hieu

I am not aware of any special reason it is such way as you point out. Feel free to propose any improvement or new design.  
The thing I can think of is that you probably would need to maintain a mini cache and mini batch (going to the backend storage) to feed into the Iterator.

Thanks.

Jerry

Thanks.

Jerry

On Fri, Jul 26, 2019 at 11:24 AM Hieu Nguyen <ntrh...@...> wrote:
When I look at the OrderedKeyValueStoreAdapter class, in methods getSlice() or getSlices(), objects of type RecordIterator<KeyValueEntry>  are converted to objects of type EntryList (StaticArrayEntryList). This, basically, breaks the iterator fashion since all data are collected and materialized. In many cases, this is very inefficient. For example, with multi-query enabled and I want to do g.V().has("name", "xxx").out().limit(50) and assume g.V().has("name", "xxx") result has 1k vertices, out() would trigger 1k concurrent requests and may return thousands of vertices although it is likely that with much fewer requests it can satisfy the limit(50). 

With an iterator fashion, it may try to do next() until it reaches the limit (50) and then stops.

I believe replacing EntryList by an iterable type to enable fully iterator-way of retrieving and processing data will benefit JanusGraph efficiency. My question is is there some reasons that EntryList was designed at the first place or there are some fundamental drawbacks of using iterator instead of EntryList? This would save time a lot since I plan to spend my effort to improve this.

--
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/1d6bd615-d355-4618-9a7e-5a3a687939ef%40googlegroups.com.


Replacing EntryList by an iterable type

Hieu Nguyen <ntrh...@...>
 

When I look at the OrderedKeyValueStoreAdapter class, in methods getSlice() or getSlices(), objects of type RecordIterator<KeyValueEntry>  are converted to objects of type EntryList (StaticArrayEntryList). This, basically, breaks the iterator fashion since all data are collected and materialized. In many cases, this is very inefficient. For example, with multi-query enabled and I want to do g.V().has("name", "xxx").out().limit(50) and assume g.V().has("name", "xxx") result has 1k vertices, out() would trigger 1k concurrent requests and may return thousands of vertices although it is likely that with much fewer requests it can satisfy the limit(50). 

With an iterator fashion, it may try to do next() until it reaches the limit (50) and then stops.

I believe replacing EntryList by an iterable type to enable fully iterator-way of retrieving and processing data will benefit JanusGraph efficiency. My question is is there some reasons that EntryList was designed at the first place or there are some fundamental drawbacks of using iterator instead of EntryList? This would save time a lot since I plan to spend my effort to improve this.

401 - 420 of 1585