Thanks for looking into my suggested enhancements.
I agree that it is not easy to see which Interfaces are really only renamed
instances of the original API and which Interfaces are new or add features, so
I will move the renamed Interfaces to another package.
In the enhanced API there is indeed
> Your approach is sensible if you have a lot of tooling / code around your
> relational model.
I don't have.
> Do you use JPA or some other ORM or just plain JDBC ?
None. I'm using PHP for the front end and Java for services using
Thrift for communication between the PHP and Java.
> You might
Ok, makes sense.
It just hard to see what is new in that package and what is just "hiding" the
original API.
Probably I don't know enough about type/class system to understand the
implication of having properties and relationships on top of property-names,
properties, relationships, relationsh
I had to wrap many of the classes, because of the return types of several
methods. org.neo4j.collections.graphdb.Node does not extend
org.neo4j.graphdb.Node, even though all methods of org.neo4j.graphdb.Node are
also defined in org.neo4j.collections.graphdb.Node.
I realize this makes the design
Yes,
IT seems so. Will check with Toni.
/peter
Sent from my phone.
On Jul 23, 2011 2:11 PM, "Jörg Richter" wrote:
>
> Meanwhile I tried a 3rd test scenario: Activator and all neo packages in
one bundle again, but in a proper one (additional inlining of embedded jars
suppressed). Same error: "No
I don't understand why you wrapped _all_ the classes, this will make this
package very brittle as it has to copy all API changes?
I rather thought of a better / fluent / more usable API on top of the existing
one.
something like
new Graph(gbd).autoIndex("name")
.node("name","Niels")
Traverser and Index are wrapped too now, so the entire API as can be accessed
from GraphDatabaseService is now available in enhanced API version.
The API is a drop-in replacement, all that needs to be done to make an
application work against the enhanced API, is to change imports.
From: pd_afi
Cool.
Good luck. Check out:
https://github.com/tinkerpop/gremlin/wiki/Path-Optimizations
See ya,
Marko.
http://markorodriguez.com
On Jul 23, 2011, at 10:44 AM, Michael Hunger wrote:
> Especially in comparison to the raw Neo4j performance.
>
> Would be interesting to see both, code and
Meanwhile I tried a 3rd test scenario: Activator and all neo packages in one
bundle again, but in a proper one (additional inlining of embedded jars
suppressed). Same error: "No index provider 'lucene' found".
To run the various test scenarios checkout the respective tag, as described:
https://
Especially in comparison to the raw Neo4j performance.
Would be interesting to see both, code and times side by side.
Cheers
Michael
Am 23.07.2011 um 18:40 schrieb Josef Holy:
> Thanks a lot guys for quick and comprehensive answers!
>
> I was assuming that Gremlin serves only for Pipes assemb
Thanks a lot guys for quick and comprehensive answers!
I was assuming that Gremlin serves only for Pipes assembly which shouldn't
impact the overall performance too much. We've 'hit the ceiling' with
implementing various custom traversals with native neo4j APIs - the algorithms
are quite length
Hi,
Finally, one point to add.
If I only need to do a ShorestPath over a particular edge type or a "find all
paths" between two vertices and I'm using Neo4j as the graph backend, then I
will drop down and use Neo4j's Algo library. This is because their ShorestPath
implementation is bi-directio
Hey,
Groovy is only used to compile a statement like "g.v(1).out.in.blah" to a Pipes
which is native Java. As such, once the compilation is complete (milliseconds),
it is simply native Java (This is not completely true as there are some Gremlin
specific pipes). Next, for the relationship betwee
Hi John,
the algorithm is written to dodge these kinds of pitfalls. Maybe there's
some issue with the implementation, but in principal it should make no
difference. I'll look at it when I get the time (I wrote that
implementation).
2011/7/23 John cyuczieekc
> Hey guys, me bugging you again :)
>
I would gladly try to catch up with Niels but from what I've read (from his
prev. emails) I hardly understand what he was talking about (implying I am
no way near as smart to understand that; which might mean I am simply
missing the background/unstated-assumptions or focusing fail :)) [also I
don't
Peter,
no problem, take your time.
I see your super bundle test running OK in pax exam, but with an independant
deployment scenario "No index provider 'lucene' found" is a persisting error.
Meanwhile I tried the approach you suggested: having the neo-super-bundle and
my activator as separate
Right, there could be even a faster ways but they would need a few additional
methods in
NodeManager :)
Cheers
Michael
Am 23.07.2011 um 15:30 schrieb John cyuczieekc:
> Hey Michael,
> I took a very quick look, I think understand it, looks like it attempts to
> get nodes by id starting from 0
Hey Michael,
I took a very quick look, I think understand it, looks like it attempts to
get nodes by id starting from 0 until highest possible ID.
public synchronized boolean hasNext()
{
while ( currentNode == null && currentNodeId <= highId )
{
try
Perhaps you can catch up with Niels Hoogeven who's currently implementing
Collection data structures, B- and R-Trees to be transparently mapped into
graph structures at:
https://github.com/peterneubauer/graph-collections
Cheers
Michael
Perhaps you should describe the intent / idea behind your
Hail :)
Beware, lot of noise follows (ie. webnoise kinda noise), while I thank
anyone in advance for reading, I must also apologize for failing to be
concise :-"
On Sat, Jul 23, 2011 at 10:42 AM, Michael Hunger <
michael.hun...@neotechnology.com> wrote:
> John,
>
> no problem :)
>
> You pointed ou
An internal implementation would be probably faster.
If timing is that critical for you, you can have a look in
EmbeddedGraphDbImpl.getAllNodes() and implement a similar solution for
relationships.
Cheers
Michael
Am 23.07.2011 um 04:20 schrieb John cyuczieekc:
> Hey Jim,
> I am sort of glad
John,
no problem :)
You pointed out both problems:
- cold caches
- lots of rels on the one side
There are some performance implications of loading millions of rels from disk.
We'll be working on improving those in 1.5.
The easiest way to solve that is to switch start and end-node which you al
Felipe,
Your approach is sensible if you have a lot of tooling / code around your
relational model.
Do you use JPA or some other ORM or just plain JDBC ?
You might have a look at Spring Data Graph cross-store approach:
http://bit-ly/sdg-html#cross-store (and perhaps Spring Data Graph in genera
If you look at the comments of the post -
groovy is only that slow if you implement all the algorithm details in groovy !
Gremlin uses blueprints which is written in Java. Gremlin is just a DSL on top
of that API so it is just used for the construction of the underlying pipeline.
Anyway, easies
Hi all,
has someone on this list any practical experience with using Gremlin for
traversing the EmbeddedGraphDatabase in a production environment? What
interests me is how it performs compared to the traversal algorithms written
directly against Neo4j APIs (using Traverser, TraversalDescription
25 matches
Mail list logo
