I think my explanation was not clear as it should be.
I wasn't suggesting to replace the relationships with a node, but to shadow the
relationshiptypes with a node.
Let's say we have two relationshiptypes, KNOWS and FRIEND, where we want to
state that friends form a subset of the people a perso
It cannot directly be done through the standard API, but of course it can be
implemented.
I do this myself in an application I am building. For every RelationshipType, i
create a Node and between those Nodes there can have subtyping relationships.
To make lookup fast, I use the node-id of the R
Good decision. Immediately signed up.
> From: peter.neuba...@neotechnology.com
> Date: Wed, 30 Nov 2011 13:55:44 +0100
> To: user@lists.neo4j.org
> Subject: [Neo4j] Moving to u...@neo4j.org
>
> Hi all,
> we are going to move from mailman to google groups,
> http://groups.google.com/a/neo4j.org/g
be a patch out there to provide some additional
> wildcard/range capabilities for these Analyzers. Note also that in general,
> Solr analyzers/filters can be used with Lucene by themselves.
>
> Rick
>
> -Original Message-
> From: user-boun...@lists.neo4j.org [mailto:user
In order to have proper sort order for Strings with diacritical characters, I
started using Lucene's ICUCollationKeyAnalyzer. This indeed gives the proper
sort order for queries, but for some reason wild card queries no longer seem to
work. This applies for both the normal CollationKeyAnalyzer
I noticed work on supernodes being committed to GitHub. Looking forward seeing
this and in 1.6-SNAPSHOT. I would like to test this sooner rather than later.
The node#getDegree methods are a great addition.
Niels
> From: peter.neuba...@neotechnology.com
> Date: Tue, 22 Nov 2011 15:51:15 +0100
>
hopefully this will help get you pointed in the right direction.
>
> Rick
>
>
>
> ____
> From: user-boun...@lists.neo4j.org [user-boun...@lists.neo4j.org] On Behalf
> Of Niels Hoogeveen [pd_aficion...@hotmail.com]
> Sent: Friday, N
this will help get you pointed in the right direction.
>
> Rick
>
>
>
>
> From: user-boun...@lists.neo4j.org [user-boun...@lists.neo4j.org] On Behalf
> Of Niels Hoogeveen [pd_aficion...@hotmail.com]
> Sent: Friday, November 11, 2011 9:27 AM
> To: user@lists.neo4j.org
>
anyone?
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Thu, 10 Nov 2011 20:20:46 +0100
> Subject: [Neo4j] Lucene sort with diacritic characters
>
>
> When retrieving items from a Lucene index, using the sort method, it seems
> the order doesn't abide proper rules for sort
When retrieving items from a Lucene index, using the sort method, it seems the
order doesn't abide proper rules for sorting diacritic characters.
For example, Århus comes later in the list than Zürich and Ḩalab comes later
than Žužemberk.
Can someone help me solve this?
Niels
my brain is in jet lag mode :-\
> On Oct 27, 2011 7:26 PM, "Niels Hoogeveen"
> wrote:
>
> >
> > I see I made a bit of a mistake with this one. The gist of the solution
> > remains, but I made a mistake dealing with the directions of relationship.
> > It s
I see I made a bit of a mistake with this one. The gist of the solution
remains, but I made a mistake dealing with the directions of relationship.
It should be something like this.
public boolean areConnected(Node n1,Node n2, RelationshipType relType,Direction
dir) {
Direction dir2 = null;
i
I gave a different approach in another post, but I am actually not sure if I
understand the problem correctly.
You give a signature: public boolean areConnected(Node n1,Node n2,Relationship
rel,Direction dir)
If you simply want to check if the given Relationship connects n1 and n2 with
the gi
There is one caveat to this method, you'd have to know which node is most
densely connected.
Suppose one of the nodes has 100,000 relationships (incoming and outgoing) and
the other node has only a few relationships, then you'd want to iterate over
the relationships of the second node.
A sol
I concur. In my opinion Neo4j is more a storage engine with certain storage
features than a database management system. This is already exemplified by the
absence of a query language as primary interface.
The author is therefore wrong in his assessment that there is no separation of
logical mo
Hijack alert (going completely off topic)
I noticed the following statement: "all reasoning is best with a linked list
data structure."
When looking at the underlying store we see that the RelationshipRecord indeed
forms two linked lists, one for the incoming side of the relationship and one
fo
ith types
> WORKS_AT and REFERS_TO might have something in common (e.g. they both have
> to specify a boss who gives them orders).
>
> For now I don't think my problem requires interfaces before it can be be
> solved, but I only just started so who knows :)
>
> Jon
> O
e kind like "object blobs"), so in our metamodel, they are not stored as
> nodes, relationships, and properties, but rather, as a JSON blob, serialized
> as a string to a node property. That has worked out really well. When we do
> need to filter/manipulate those, we do them
in
> > for which it was OK to be "opaque" - e.g. although the structures were deep
> > and complex, they did not require searchability or traversability (e.g.
> > they were kind like "object blobs"), so in our metamodel, they are not
> > stored as no
You raise interesting questions, most of them very much related to the work I
did on Enhanced API.
Let me start with the distinction between Node and Relationship, which in my
opinion too is a bit artificial. I understand when creating a graph database,
it is helpful to have something like ver
>
> On Sat, Sep 24, 2011 at 5:00 PM, loldrup wrote:
>
> >
> > Niels Hoogeveen wrote:
> > >
> > > I just posted an example on how to use HyperRelationships:
> > >
> > >
> > https://github.com/peterneubauer/graph-collections/wiki/Hyper
when
> reading, or fails with a ConcurrentModificationException when reading and
> data is changed.
>
> On Sat, Sep 24, 2011 at 6:00 AM, Niels Hoogeveen
> wrote:
>
> >
> > A quick skim of the code shows me you have a baseNode which is an
> > entrypoint for the UL
the data within the graph, not of
> the given instantiation of the class, e.g. what happens when one thread gets
> an instance of ULL based off a given node and is iterating over it, then
> another thread gets an instance of a ULL and writes into it.
>
> Cheers
> Bryce
>
> On
It looks really cool.
I always find it fun to create something and later find out it is an already
known construction (something worth inventing).
Anyway, I pulled your code and will removed the dependencies to the Enhanced
API stuff this week. After that we can start adding some documentation.
into a collection stored in a graph data structure.
>
> Thoughts?
>
> Cheers
> Bryce
>
> P.S. Peter, I had thought to remove the passing in of the graph database and
> instead just getting it from the node, or only passing in the graph database
> and creating
Hi Bryce,
I really like what you are trying to achieve here.
One question:
Instead of having NodeCollection, why not have GraphCollection. That way we can have collections of both Relationships and
Nodes.
Niels
> Date: Fri, 16 Sep 2011 17:37:29 +1200
> From: bryc...@gmail.com
> To: user@lists.n
Bryce's point makes perfect sense. The argument graphDb().createNode() gives
the constructor an instance of Node, which contains a reference to the
database, so there is no real need to additionally supply the database instance.
Of course his example would have been less confusing if he'd writte
a's coolest Bring-a-Thing party.
>
>
>
> On Thu, Sep 15, 2011 at 1:48 PM, Niels Hoogeveen
> wrote:
> >
> > Thanks to the good work of Davide, graph-collections now contains an
> > implementation of Radix-tree. See: http://en.wikipedia.org/wiki/Radix_tree
Thanks to the good work of Davide, graph-collections now contains an
implementation of Radix-tree. See: http://en.wikipedia.org/wiki/Radix_tree
This particular datastructure can be used to store nodes sorted by a String
value, very handy when you want to create associative arrays in Neo4j.
Niels
Peter,
I'd gladly put out a piece of code demonstrating the use of IndexRelationships,
using this "LIVES_IN" example. Though I get the impression the question here
relates to the normal relationship index. However when "supernodes" (still
don't like that term for densely connected nodes) come
or given different situations.
>
> That does bring up a question though, there was some discussion a while ago
> about some functionality along the lines of IndexedRelationship being pulled
> into the core, so is that overkill for now if there is going to be another
> core offering lat
good for given different situations.
> >
> > That does bring up a question though, there was some discussion a while ago
> > about some functionality along the lines of IndexedRelationship being pulled
> > into the core, so is that overkill for now if there is goi
a large change?
>
> Maybe SortedTree would have two iterator's available a key_value
> relationship iterator, and a node iterator. Having a quick look at it now
> it seems that it could work ok that way without introducing much code
> duplication.
>
> On Thu, Sep 8, 2011 at 12:46
and these are all stored as strings. If it was going to help
> with either memory or performance then I would be keen to migrate this to
> two longs.
>
> Cheers
> Bryce
>
> On Thu, Sep 8, 2011 at 11:07 AM, Niels Hoogeveen
> wrote:
>
> >
> > Great work Bry
Great work Bryce,
I do have a question though.
What is the rationale for the restriction mentioned under "1)". Do you need
this for the general case (to make IndexedRelationshipExpander work correctly),
or do you need it for your own application to throw that exception? If the
latter is the cas
Hi Bryce,
Sorry for my belated response. I have been away for a couple of days and wasn't
able to check my emails.
I am glad you took the time to look into the IndexRelationship module. It
certainly could use some scrutiny.
Remarks:
1) Good catch... Something the unit test didn't catch because
Correct, turing completeness is not the lower bound for non-guaranteed
termination.
It is however possible to have some forms of recursion without sacrificing
guaranteed termination. Neo4j traversals, memorizing visited paths,
relationships or nodes are an example (Note, it would be nice to hav
Hi Peter,
Thanks for sharing this. Layout-wise, the solution you present is not really
different from what Enhanced API does with regard to n-ary relationships. I
would like to know if there is an elegant creation pattern for n-ary
relationships, or do you have to rely on a manual creation of t
hs at any point and thus visualize
> what's happening in the graph to illustrate :)
>
> /Peter
>
> On Monday, August 29, 2011, Niels Hoogeveen
> wrote:
> >
> > In the last week I have been working on a Neo4j API in Scala, taking
> navigation in the graph a
In the last week I have been working on a Neo4j API in Scala, taking navigation
in the graph as primary.
Just like the Enhanced API written in Java, the Scala API generalizes each
element (Node, Relationship, RelationshipType, property name and property
value) of the Neo4j database as being a
w.linkedin.com/in/neubauer
> Twitter http://twitter.com/peterneubauer
>
> http://www.neo4j.org - Your high performance graph database.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Brin
Jim,
Can you tell me how to add my suggestions for a solution to this problem to
your issue tracker?
Niels
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Tue, 16 Aug 2011 16:33:04 +0200
> Subject: Re: [Neo4j] partitioning the relationship store
>
>
> The partitioning is
The partitioning is a solution to the densely-connected node problem, but would
also allow for the iteration over RelationshipTypes/Directions, another feature
I would very much like to see.
I have posted suggestions on how to approach this problem and would like to add
those suggestions to the
> Sent from my phone.
> On Aug 16, 2011 1:52 PM, "Niels Hoogeveen"
> wrote:
> >
> > Yesterday, I added subtyping to Enhanced API.
> >
> > Suppose an application has UserGroups, Users and Roles, where both
> UserGroups and Users are Vertices and
At the risk of coming off as an utter bore, I would like once more to raise
awareness for the fact that the relationships of a node are currently stored as
one linked list. The downside of this has been discussed in many posts, so I
shan't rehash the points.
It's just that whatever I try to i
Yesterday, I added subtyping to Enhanced API.
Suppose an application has UserGroups, Users and Roles, where both UserGroups
and Users are Vertices and Roles are BinaryEdges. There can be different
predefined Roles, such as ADMINISTRATOR, EDITOR, MEMBER, GUEST.
With subtyping it is possible to
, but after making changes to the relationships, does the graph service
> automatically allow me to navigate from Person to ContactInfo to Address?
>
> -Original Message-
> From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On
> Behalf Of Niels Hoogeveen
All your existing relationships will remain the same, unless you remove them
yourself.
If you make your hypothetical changes, all Persons will keep a relationship to
Address through the RESIDES_AT relationship, even though you now create a new
ContactInfo entity that connects to Address too.
Hi Emerson,
Over the last couple of weeks, I have been working on an implementation of
n-ary relationships on top of Neo4j. I also detailed how n-ary relationships
could in principle be implemented in the database kernel (see:
http://lists.neo4j.org/pipermail/user/2011-August/011191.html).
Ri
volved in creating connections between facts. Is anyone seeing a
> > more fluent/concise approach to this? Also, did you have some ideas
> > about how to traverse or query these hyperedges?
> >
> > Cheers,
> >
> > /peter neubauer
> >
> > GTalk:
r
> Twitter http://twitter.com/peterneubauer
>
> http://www.neo4j.org - Your high performance graph database.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
&g
eubauer
> Twitter http://twitter.com/peterneubauer
>
> http://www.neo4j.org - Your high performance graph database.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
>
>
which maps from String to internal ID (integer)
> used in Neo4j).
>
> 2011/8/10 Niels Hoogeveen
>
> >
> > I find myself using some pretty long property names, like
> > "org.neo4j.collections.graphdb.node_id" and wonder if this has an impact on
> > per
I find myself using some pretty long property names, like
"org.neo4j.collections.graphdb.node_id" and wonder if this has an impact on
performance.
Niels
From: pd_aficion...@hotmail.com
To: user@lists.neo4j.org
Subject: length of property names
Date: Mon, 8 Aug 2011 15:44:20 +0200
Quick
I should of course market this work better.
So hereby the statement: NOW with nice and handy images, free of charge!!!
Niels
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Wed, 10 Aug 2011 01:19:42 +0200
> Subject: [Neo4j] Enhanced API wiki page
>
>
> Today I updated the
Today I updated the wiki page for Enhanced API. Since the last edit many
changes have taken place, so it was to to reflect those changes on the wiki
page.
See: https://github.com/peterneubauer/graph-collections/wiki/Enhanced-API
I also changed what was previously called an "EdgeRole" into a "C
il.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] Enhanced API rewrite
>
> I ready to jump in too ;-)
>
> On Mon, Aug 8, 2011 at 3:37 PM, Niels Hoogeveen
> wrote:
>
> >
> > I can probably find the time for that. It would be fun working on these
> > i
Quick question: what is the performance impact of the length of a property
name?
Niels
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
o4j.org - Your high performance graph database.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
>
>
>
> On Sun, Aug 7, 2011 at 4:30 PM, Niels Hoogeveen
> wrote:
While I am at it, let's post another brain dump.
A couple of weeks ago, I worked on SortedTree/IndexRelationships in an attempt
to solve the densely-connected-node-problem.
SortedTree is a Btree layed-out in the graph, sorted by some function on a node
(eg. the nodeId, or a property value).
eotechnology.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] Node#getRelationshipTypes
>
> 2011/8/6 Niels Hoogeveen
>
> >
> > This is the thread about store layer changes for type/direction, and in my
> > opinion this is still quite low hanging fruit. Sure, t
Over the last couple of weeks, I have been working on an Enhanced API for
Neo4j, and would like to make some suggestions on how some changes to the store
layout can improve Neo4j and make the implementation of the Enhanced API
simpler and more transparent.
Let me start with a definition of a r
er.com/peterneubauer
>
> http://www.neo4j.org - Your high performance graph database.
> http://startupbootcamp.org/- Öresund - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
>
>
>
> On Sat, Aug 6, 2011
Today I added fluency to the API design.
It is now possible to write:
Db().createVertex()
.setProperty(Name, "John")
.setProperty(Age, 29)
.addEdgeTo(june, WIFE)
I also added support for VertexTypes, which is nothing more and nothing less
than a Vertex with a unique name and a class name to in
low hanging.
>
> Den lördagen den 6:e augusti 2011 skrev Mattias
> Persson:
> > I would not consider this low hanging fruit btw
> >
> > Den onsdagen den 3:e augusti 2011 skrev Niels
> > Hoogeveen:
> >>
> >> Hmmm... Does that require the inclus
What you describe here is a ternary edge, something I try to cover in the
Enhanced API.
Your film example can be modeled as follows:
There is an Edge "STARS" with the EdgeRoles: "Actor", "Film", "Role".
We can now state:
STARS
-- Actor -- Brad Pitt
-- Film -- Fight club
-- Role -- Tyler Durd
Today I pushed a major rewrite of the Enhanced API. See:
https://github.com/peterneubauer/graph-collections/tree/master/src/main/java/org/neo4j/collections/graphdb
Originally the Enhanced API was a drop-in replacement of the standard Neo4j
API. This resulted in lots of wrapper classes that need
Hi Boris,
What will be your decision procedure to determine what edges will be marked as
heavy and which will be marked as light? Even if you establish a fixed ratio,
you will still need to decide what relationships belong in one category and
which belong in the other?
Could you elaborate a lit
Is it possible for you to use the batch inserter, or does the data you are
loading require a lot of lookups?
Niels
> From: jvcole...@gmail.com
> Date: Wed, 3 Aug 2011 17:57:20 -0300
> To: user@lists.neo4j.org
> Subject: [Neo4j] Memory overflow while creating big graph
>
> Hi,
>
> I'm trying to
.
Niels
> Date: Wed, 3 Aug 2011 16:31:04 +0200
> From: matt...@neotechnology.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] Node#getRelationshipTypes
>
> A golden helicopter might do the trick :)
>
> 2011/8/3 Niels Hoogeveen
>
> >
> > How does one p
That should be "without having to do any lookups"
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Wed, 3 Aug 2011 13:37:44 +0200
> Subject: Re: [Neo4j] Batch find
>
>
> The batch insert is intended to push data into the database with having to do
> any look ups.
> You coul
The batch insert is intended to push data into the database with having to do
any look ups.
You could preprocess your input data, such that it can be loaded in one go. You
could for example read you input file against an existing database, fetch the
ID's of nodes and relationships that contain
e methods to TraversalDescription will in
> effect do the same thing up until the time where Neo4j is less ambivalent
> regarding traversal frameworks.
>
> 2011/8/2 Niels Hoogeveen
>
> >
> > It looks like this does the same I suggested. It's a bit clunkier, but I
&g
eniences to have it on par with production quality. And
> that kind of time haven't been allocated yet.
>
> I appreciate your thoughts and time on all this!
>
> Best,
> Mattias
>
> 2011/8/3 Niels Hoogeveen
>
> >
> > I would like to make a
least making sure the whole chain have been loaded).
> > I've never found a use case for it myself and this is the first I've heard.
> >
> > 2011/8/1 Niels Hoogeveen
> >
> > >
> > > I have two specific use cases for these methods:
>
raverse( Path startPath, Path...
> additionalStartPaths );
> TraversalDescription#traverse( Iterable startPaths );
>
> that would be rather similar, wouldn't it?
>
> 2011/7/30 Niels Hoogeveen
>
> >
> > I would be all for it if this could become par
quire a
> full iteration (or at least making sure the whole chain have been loaded).
> I've never found a use case for it myself and this is the first I've heard.
>
> 2011/8/1 Niels Hoogeveen
>
> >
> > I have two specific use cases for these methods:
> >
Last couple of days I have worked improving upon the Enhanced API and made some
progress unifying Properties and Relationships.
For some time, I have wanted to have a traverser which I can set up so that it
returns a collection of properties. After all what we want to present in an
application
his operation again?
>
> Cheers
>
> Michael
>
> Am 31.07.2011 um 18:59 schrieb Niels Hoogeveen:
>
> >
> > Good point.
> > It could for all practical purposes even be Iterable so
> > they can be lazily fetched, as long as the underlying implementat
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] Brainstorming on my project: neo4john
>
> Hey Niels, thanks for the concise reply.
>
> On Sun, Jul 31, 2011 at 5:10 PM, Niels Hoogeveen
> wrote:
>
> >
> > Hi John,
> >
> > I think when appro
Interesting thought, and it is certainly true that indexing is much less of a
concern in a graph database than in a normal RDBMS where generally every table
needs to have a primary key and where you need to have an index on the primary
key to be able to do joins (at least to do them somewhat qu
Good point.
It could for all practical purposes even be Iterable so they
can be lazily fetched, as long as the underlying implementation makes certain
that any iteration of the RelationshipTypes forms a set (no duplicates).
There is no need to have RelationshipTypes in any particular order, and
Hi John,
I think when approaching a project there are two distinct issues at play, one
is the tooling level,
another is the actual solution you are trying to create for an actual problem.
When looking at the tooling level it is great to have as much covered as
possible.
Neo4j offers a graph
d.
> >
> > neo4j-kernel-1.4-SNAPSHOT.jar 817,935 bytes
> > sha1: a20720ece824b372520b7afde080cdc83abb5501
> >
> > Thanks for the hints! All this maven knowledge will prove useful.
> > John.
> >
> >
> > On Sun, Jul 31, 2011 at 12:57
a20720ece824b372520b7afde080cdc83abb5501
>
> Thanks for the hints! All this maven knowledge will prove useful.
> John.
>
>
> On Sun, Jul 31, 2011 at 12:57 AM, Niels Hoogeveen > wrote:
>
> >
> > Could you check if the neo4j kernel jar file maven adds to class
--
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Sun Jul 31 00:37:19 CEST 2011
> [INFO] Final Memory: 38M/359M
> [INFO]
>
> e:\down\13th-floor-bdb
7;ve
> >>>> already fixed this)
> >>>>
> >>>> Either way, my impression of what was happening is that some files got
> >>>> deleted, except some ie. the log, which were still open/in use, and maybe
> >>>> when recovery was tr
annot yet figure out who creates that file
> and to make sure it's being closed
>
> John.
>
> On Sat, Jul 30, 2011 at 11:09 PM, Niels Hoogeveen > wrote:
>
> >
> > The problem is indeed related to not properly closing the bdb database, and
> > that i
While working on Enhanced API, I realize two crucial method are missing on the
Node interface of the standard API:
RelationshipType[] getRelationshipTypes();
RelationshipType[] getRelationshipTypes(Direction);
For Enhanced API, I'd like to be able to plug in different Relationship
implementati
; [WARNING] The POM for org.apache.maven:maven-plugin-api:jar:2.0.6 is
> >>>> missing, no dependency information available
> >>>> [WARNING] The POM for org.apache.maven:maven-project:jar:2.0.6 is
> >>>> missing, no dependency information av
tivePath' points at wrong local POM @ line 3,
> column 11 -> [Help 2]
>
> before I could do anything with maven...
> I'll skip trying to make maven to work for me for now, don't feel like it :)
>
> *I'm not qualified to fix this with maven, sorry*
> Joh
g we've been discussing :)
>
> 2011/7/29 Niels Hoogeveen
>
> >
> > Great, I would much rather see this become part of the core API than have
> > this as part of the Enhanced API.
> > To make things work correctly, one important change to core is needed: The
dding stuff to the framework in a side track and will surely add some
> aspect of composable traversers also.
>
> 2011/7/29 Niels Hoogeveen
>
> >
> > I'd like to take a stab at implementing traversals in the Enhanced API. One
> > of the things I'd like
. Parsing A then X of B-> in
> dbBackward for example can only be done with a cursor...
>
> Either way, I'm taking a look on that bdb-index thingy; will report back if
> I have any ideas heh
>
> John.
>
> On Thu, Jul 28, 2011 at 9:42 PM, Niels Hoogeveen
> wrote:
sn't look pretty if you're trying
> to see what changed
>
> John.
>
>
> On Thu, Jul 28, 2011 at 7:36 PM, Niels Hoogeveen
> wrote:
>
> >
> > Trying to find something useful to hide the implementation book keeping of
> > Enhanced API, I tried o
rocesses that cannot access the same java resource ie. in
> another jvm or computer tho accessing the same database - I guess this rules
> out embedded?) ? if any locks...
>
> On Fri, Jul 29, 2011 at 1:30 AM, Niels Hoogeveen
> wrote:
>
> >
> > I'd like to take
I'd like to take a stab at implementing traversals in the Enhanced API. One of
the things I'd like to do, is to make traversals composable.
Right now a Traverser is created by either calling the traverse method on Node,
or to call the traverse(Node) method on TraversalDescription.
This makes
g/- Öresund - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
>
>
>
> On Thu, Jul 28, 2011 at 10:36 AM, Niels Hoogeveen
> wrote:
> >
> > Trying to find something useful to hide the implementation book kee
Should read: The retrieved indexName is actually garbage.
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Thu, 28 Jul 2011 19:36:21 +0200
> Subject: [Neo4j] bdb-index
>
>
> Trying to find something useful to hide the implementation book keeping of
> Enhanced API, I tried
Trying to find something useful to hide the implementation book keeping of
Enhanced API, I tried out dbd-index as can be found
here:https://github.com/peterneubauer/bdb-index
It looks interesting, but fails its tests. When recovering it performs
BerkeleyDbCommand#readCommand from the log. The r
1 - 100 of 281 matches
Mail list logo
