t; in
> >> >>> like 0 to 66 to 310 seconds (depending on its position)
> >> >>>
> >> >>> is a show stopper for me, especially because I want to base everything
> >> on
> >> >>> just nodes (without properties) and their relationships.
hat is acquireLock() doing in SortedTree ?
> is removeProperty causing neo4j to acquire a lock on the Node? or its
> properties?
> also does that property need to exist? seems like not
> interesting :)
>
>
> On Wed, Jul 27, 2011 at 8:48 PM, Niels Hoogeveen
> wro
DatabaseService) is not visible
>
> 2) org.neo4j.collections.graphdb.impl.NodeLikeImpl.getRelationships()
> The return type is incompatible with
> RelationshipContainer.getRelationships()
>
> 3)
> org.neo4j.collections.graphdb.impl.NodeLikeImpl.getRelationships(RelationshipT
When iterating over all nodes, you also pull the reference node (with id = 0),
which probably doesn't have the requested property.
If you want to list all properties of a node, it's better to use a construct
like:
for(String key: node.getPropertyKeys()){
System.out.println(node.getProperty(ke
it doesn't seem useless or
> cluttering... (note however I never actually, yet, used fork&pull but only
> read about it on github xD)
>
> Thanks to all, for wasting some time reading this,
> Greeting and salutations,
> John
>
> On Wed, Jul 27, 2011 at 8:48 PM, Niels Hoogeveen
Integrated IndexedRelationships functionality into the Enhanced API, so
relationships of a certain type are maintained in a Btree, while they can be
manipulated through the API just like any other relationship.
Still need to test this one.
As mentioned earlier today, HyperRelationships and Enhan
Hi Sambodhi,
One of the means to organize complexity is by adding meta information to your
database. This first of all helps you organize what relationships and
properties belong to what sort of node, it may also help answer questions such
as: what nodes belong to what type/class.
Niels
> Dat
I just posted an example on how to use HyperRelationships:
https://github.com/peterneubauer/graph-collections/wiki/HyperRelationship-example
There is now a proper test for HyperRelationships, so I hereby push the
software to Beta status.
Please try out the Enhanced API and HyperRelationships a
ter.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.
> >
> 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.
>
>
>
>
Enhanced API and HyperRelationships
>
> Hi Niels --
>
> Very interesting stuff you're doing. Any chance that Scala app of your
> is open source? Would love to see the impact of using your enhanced
> API vs not using it.
>
> Cheers,
>
> -EE
>
> On
I just ported my own application 12kloc of Scala code to use the Enhance API
and got it working. Of course more thorough testing needs to be done, but it
proves that at least in the case of my own application the Enhanced API can
work as a drop-in replacement.
Niels
> From: pd_aficion...@hotm
A first stab at implementing the Enhanced API and HyperRelationships is
finished. It still needs thorough testing, so this is PRE-ALPHA quality.It also
still lacks proper documentation (java docs).The source code can be found
at:https://github.com/peterneubauer/graph-collections/tree/master/src
The implementation of HyperRelationships needs another day of work, though the
hard parts are finished now.
Time to explain the inner workings of HyperRelationships.
HyperRelationships are a generalization of the binary relationships found in
Neo4j.
Instead of creating a relationship from a
RelationshipType is not really a type in the conventional sense of the word.
RelationshipType is for all practical purposes a label assigned to a
Relationship for the purpose of navigation.
You could also say that nodes are typed through the relationships attached to
them. So from the perspect
/www.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 coole
Today I wrote a piece about the Enhanced API and about HyperRelationships, I
have been working on over the last couple of days.
See: https://github.com/peterneubauer/graph-collections/wiki/Enhanced-API
The API as presented in the graph-collections repo on Git is not feature
complete yet with r
Are you sure this is true, Mattias?The response time of a getRelationship call
depends on the total number of relationships on the node. So it makes a
difference which side of the relationship makes the call. It is always faster
to ask it from the side that has the lowest total number of relati
Especially keeping the
> old names around when the things are actually unified carries too much
> "wrong" semantics.
>
> Michael
>
> Am 23.07.2011 um 22:02 schrieb Niels Hoogeveen:
>
> >
> > I had to wrap many of the classes, beca
d what property-type is for. I thought you were
> only working on n-ary relationships?
>
> Btw. you can replace those unholy if clauses with polymorphism in the enum.
>
> Are there some tests and/or examples that uses this API ?
>
> Cheers
>
> Michael
>
>
From: matt...@neotechnology.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] Hyperedges and Objects
>
> Niels,
>
> sounds like fun. Looking forward to get a look at this
>
> 2011/7/21 Niels Hoogeveen
>
> >
> > i made a start on this. It's not a
the node space. Named
> persistent maps from String to PropetyContainer would also be helpful for
> fast lookup of uris and generally for the creation of unique keys.
>
> Niels
> > Date: Thu, 21 Jul 2011 20:38:15 +0200
> > From: matt...@neotechnology.com
> > To: user@lists
gt;
> That's a perfect use case for a super trivial Lucene index, no? Would seem
> to be a much easier solution with much faster lookup...and built into Neo4J.
>
>
> From: user-boun...@lists.neo4j.org [user-boun...@lists.neo4j.org] On Behal
Last night while working on some enhancements on the Neo4J API, I set up a
method to lookup the name of a relationship, to facilitate the creation of
associated nodes.
The method I use, is to create a node (which can be found through the reference
node) and on this node create a property for ea
> sounds like fun. Looking forward to get a look at this
>
> 2011/7/21 Niels Hoogeveen
>
> >
> > i made a start on this. It's not all too difficult to enhance relationships
> > such that relationships can be created upon them, which is a first step
>
om/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 Bring-a-Thin
getOrCreate method
> * fluent, chained API for creating stuff in a readable language
> * getRelationshipCount()
> * some more that I forgot :)
>
> Michael, pulling his wishlist
>
> Am 21.07.2011 um 20:32 schrieb Niels Hoogeveen:
>
> >
> > i made a start on this.
community contribution.
>
> Cheers
>
> Michael
>
> Am 16.07.2011 um 23:08 schrieb Niels Hoogeveen:
>
> >
> > The question is how much easier a traverser can become when there were
> > dedicated hyper edges. In a binary relation it is fairly easy to define
> 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.
>
&
To simplify the use of IndexedRelationships, I added support for the use case
where relationships are placed in an index based on the value of a property of
the node added.
Hereto, I added wrappers for property types for all data types supported.
There is also a specialized version of SortedTre
fected by it. I'm
> also not sure whether we "need" or use RelationshipType (we do of course
> specify relationship types when traversing, etc.).
>
> Aseem
>
> On Mon, Jul 18, 2011 at 12:53 PM, Niels Hoogeveen > wrote:
>
> >
> > Thanks for the che
gt; Nils,
> Sounds great, I am on parental leave all summer so I can only cheer :)
>
> /peter
>
> Sent from my phone.
> On Jul 18, 2011 5:22 PM, "Niels Hoogeveen"
> wrote:
> >
> > In fact, this feature request wouldn't have to be more than a
>
sounds interesting.
>
> Would love to see that as community contribution.
>
> Cheers
>
> Michael
>
> Am 16.07.2011 um 23:08 schrieb Niels Hoogeveen:
>
> >
> > The question is how much easier a traverser can become when there were
> > dedicated hyper
In fact, this feature request wouldn't have to be more than a setNodeId(long
id) and getNodeId() method on RelationshipType. This would eliminate the need
to look up additional relationship type information through the Lucene Index.
Niels
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j
ff that 95% of applications need, and API-based approaches for the other
> 5%.
>
>
>
> -Original Message-
> From: user-boun...@lists.neo4j.org [mailto:user-boun...@lists.neo4j.org] On
> Behalf Of Niels Hoogeveen
> Sent: Monday, July 18, 2011 8:50 AM
> To:
In another thread today, I defended the schemaless nature of Neo4J, however I
believe there is one area where Neo4J has some sense of schema, which could use
some improvement in my opinion, the RelationshipType.
Whenever creating a typing layer on top of Neo4J, some duplication of
functionality
Rick,
I think adding a "node type" to neo4j is not a good idea. Different
applications have different typing needs.
My own application for example, supports multiple "node types" per node, while
"node types" can be subtyped as well.
This creates a forest of types for each node, that needs to
isHyper' method pointing out that there are
> additional methods allowing to get all further incident nodes. This is
> also a matter of performance. I think such a handling is implemented
> most efficiently within the Neo4j engine.
>
> Best regards
>
> Norbert Tausch
>
It makes perfect sense to be able to create multiple relatationships between
two nodes, once you consider that relationships have properties.
For example:
Elizabeth Taylor --MARRIED_TO [from: 1964, to: 1974]--> Richard BurtonElizabeth
Taylor --MARRIED_TO [from: 1975, to: 1976]--> Richard Burton
Hyper edges can be emulated.
Suppose you want to store the fact "John gives Pete a book".
This is indeed a ternary relationship, which would call for an hyper edge.
This fact can be stored as follows:
Some act of giving --Giver-->JohnSome act of giving --Recipient--> PeteSome act
of giving --Gi
Hi,You basically have two options. If your result set is not too big, you can
sort it in memory, though that approach may consume too much memory if the
result set is very large. In that case you can use SortedTree (see:
https://github.com/peterneubauer/graph-collections/tree/master/src/main/ja
There will indeed be a performance impact in your scenario. The relationship
store doesn't order the relationships, so all relationships attached to Node
(A) will be read.
Maybe indexed relationships is an option for you, see:
https://github.com/peterneubauer/graph-collections/wiki/Indexed-rela
e: [Neo4j] math question
>
> Hi,
>
> I suppose I would say that (xRy) is both functional and inverse functional. :)
>
> Marko.
>
> http://markorodriguez.com
>
> On Jul 12, 2011, at 12:36 PM, Niels Hoogeveen wrote:
>
> >
> > Thanks Marko,
> >
for
> every x.
> - e.g. Social Security Number, Father, BornIn
>
> Inverse functional relationships are that there is a unique x in (xRy), for
> every y.
>
> See ya,
> Marko.
>
> http://markorodriguez.com
>
> On Jul 12, 2011, at 9:39 AM, Niels Hoogeveen w
Does anyone know the proper mathematical name for a relationship with the
following properties:
For all x in X and y in Y it holds that if xRy and xR'y then R = R'.
Example:
There can be only one IS_PARENT relation from one person to another. Someone
cannot be twice parent to the same person.
Th
the normal API has been catching up with the batch API for
> many cases, and we have also moved our OSM importer to the normal API. I'm
> guessing the same might happen everywhere.
>
> On Fri, Jul 8, 2011 at 11:56 AM, Niels Hoogeveen
> wrote:
>
> >
> > I think the
, and we have also moved our OSM importer to the normal API. I'm
> > guessing the same might happen everywhere.
> >
> > On Fri, Jul 8, 2011 at 11:56 AM, Niels Hoogeveen
> > wrote:
> >
> >>
> >> I think the best solution to use the batch
The shortest path is calculated by means of traversals. During traversal,
visited nodes are read into the cache (unless those nodes are already in the
cache). It is not necessarily so that the entire graph needs to be traversed to
calculate the shortest path. If a path is found, other traversal
't know if this is the right place to ask this; but does it support
> >> a batch insert mode? When I am bulk loading data I don't have Node
> >> objects to pass around, only node ids.
> >>
> >> Thanks,
> >> Andrew
> >>
> >> On 07
scenario and how that solution would compare to the naive supernodes
> with just millions of relationships.
>
> Also I'd like to see a performance comparision of both approaches.
>
> Thanks so much for your work
>
> Michael
>
> Am 07.07.2011 um 22:24 schrieb Niels Ho
o4j] Indexed relationships
>
> Could you put these code examples into the Readme for the project or on a
> wiki page?
>
> Am 07.07.2011 um 22:11 schrieb Niels Hoogeveen:
>
> >
> > IndexedRelationship and IndexedRelationshipExpander are now in Git. See:
> > https:/
I am glad to see a solution will be provided at the core level.
Today, I pushed IndexedRelationships and IndexedRelationshipExpander to Git,
see:
https://github.com/peterneubauer/graph-collections/tree/master/src/main/java/org/neo4j/collections/indexedrelationship
This provides a solution to th
; RelationshipExpander that uses it).
> > >
> > > And in the constructor if there is no relationship to the treeNode, you
> > > create a new one, but that new treeNode is not connected to the actual
> > > node?
> > >
> > > I'm
o4j] Indexed relationships
>
> Why can't they should.n't it be possible to grab an id from the id-generator
> on creation and store it as property?
>
> Sent from my iBrick4
>
>
> Am 07.07.2011 um 16:55 schrieb Niels Hoogeveen :
>
> >
> > Hi Michael,I
The interface of org.neo4j.graphdb.Expander contains a typo.
The method addRelationsipFilter(Predicate) should be
called addRelationshipFilter(Predicate).
Niels
___
Neo4j mailing list
User@lists.neo4j.org
https://lis
Marko's solution works, because you roll back the transaction once you find a
duplicate entry.
Another solution to this problem is to use the SortedTree index in
graph-collections https://github.com/peterneubauer/graph-collections, which has
a setting that makes an index unique. This component
> >
> > I'm not sure if it should support the original relationship-traversal API /
> > methods (getRelationships(Dir,type), etc).
> >
> > Perhaps that IndexedRelationship should rather be just a wrapper around a
> > SuperNode ? So probably rename it to &quo
> HeavilyConnectedNode(Wrapper) ?)
>
> Cheers
>
> Michael
>
> Am 07.07.2011 um 12:51 schrieb Niels Hoogeveen:
>
> >
> > Finished the implementation of indexed relationships. The graph collections
> > component now contains the package
> > htt
.org
> > Subject: Re: [Neo4j] Indexed relationships
> >
> > Great work Nils!
> >
> > /peter
> >
> > Sent from my phone.
> > On Jul 4, 2011 11:39 PM, "Niels Hoogeveen"
> > wrote:
> > >
> > > Made some more changes t
> Date: Tue, 5 Jul 2011 08:27:57 +0200
> From: neubauer.pe...@gmail.com
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] Indexed relationships
>
> Great work Nils!
>
> /peter
>
> Sent from my phone.
> On Jul 4, 2011 11:39 PM, "Niels Hoogeveen"
>
Made some more changes to the SortedTree implementation. Previously SortedTree
would throw an exception if a duplicate entry was being added.
I changed SortedTree to allow a key to point to more than one node, unless the
SortedTree is created as a unique index, in which case an exception is rai
I forgot to add another recurrent issue that can be solved with indexed
relationships: guaranteed unicity constraints.
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Mon, 4 Jul 2011 01:55:08 +0200
> Subject: [Neo4j] Indexed relationships
>
>
> In the thread [Neo4j] trave
In the thread [Neo4j] traversing densely populated nodes we discussed the
problems arising when large numbers of relationships are added to the same node.
Over the weekend, I have worked on a solution for the dense-relationship-nodes
using SortedTree in the neo-graph-collections component. After
API, and can imagine using the relationship expander to
> > > > instead traverse the BTree to the final relationship to the leaf nodes.
> > > >
> > > > So if we imagine a BTree with perhaps 10 or 20 hops from the root to the
> > > > lea
d traverse the BTree to the final relationship to the leaf nodes.
> > >
> > > So if we imagine a BTree with perhaps 10 or 20 hops from the root to the
> > > leaf node, the relationship expander Michael described would complete all
> > > hops and return only the last relati
giving the illusion of direct
> > connections from root to leaf. This would certainly perform well, especially
> > for cases where there are factors limiting the number of relationships we
> > want returned. I think the request for type and direction is the first
> > obvio
imiting the number of relationships we
> want returned. I think the request for type and direction is the first
> obvious case, but we could be even more explicit than that, if we pass
> constraints based on the BTree's consistent hash.
>
> On Thu, Jun 30, 2011 at 11:36 PM, Ni
gt;
> > I just reported to Michael the runs with the latest M05 snapshot, which are
> > not very positive...
> > I have suggested an (auto) indexing of relationship types / direction that
> > is used by traversing frameworks,
> > but I ain't no graphdb-engine expert :-
nd feel free to pull good implementations in to
> graph-collections. There are f.ex. queues (with workers picking items from
> them), linked lists, limited-sized lists and more.
>
> 2011/6/30 Niels Hoogeveen
>
> >
> > For neo4j.graph-collections.list.List I sugge
nd - Innovation happens HERE.
> http://www.thoughtmade.com - Scandinavia's coolest Bring-a-Thing party.
>
>
>
> On Thu, Jun 30, 2011 at 5:28 PM, Niels Hoogeveen
> wrote:
> >
> > Today I added a List class to the graph-collections repo:
> > https://
Today I added a List class to the graph-collections repo:
https://github.com/peterneubauer/graph-collections/tree/master/src/main/java/org/neo4j/collections/list
The List class implements the java.util.List interface.
Niels
sts I run (email me if u want the code) reveal that even the number
> >> of those dense-nodes in the database greatly influences the results.
> >>
> >> I just reported to Michael the runs with the latest M05 snapshot, which are
> >> not very positive...
> &
.
> >
> > Saikat, contact me off-list for further details on what I think could be
> > done to make this port.
> >
> > On Wed, Jun 29, 2011 at 9:52 PM, Niels Hoogeveen
> > wrote:
> >
> >>
> >> Peter, I totally agree. Having the Rtree in
of the
> typing support into a btree in the collections project?
>
> On Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
> wrote:
>
> >
> > Craig,
> > Would it be possible to merge your work on Amanzi with the work the Neo
> > team has done on the Btree c
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 Wed, Jun 29, 2011 at 4:19 PM, Niels Hoogeveen
> wro
looking into storage improvement options as well as modifications to
> retrieval of that many relationships at once.
>
> Cheers
>
> Michael
>
> Am 29.06.2011 um 17:13 schrieb Niels Hoogeveen:
>
> >
> > I achieve more or less the same result placing the relat
roup' nodes. Each 'group'
> node then has again many relationships to other nodes.
>
> Although this helps, it is a very ugly solution.
>
> Best regards
>
> Norbert Tausch
>
>
> Am 29.06.2011 16:07, schrieb Niels Hoogeveen:
> > Recently I ha
stom distribution of, for
> example, strings and category indexes.
>
> For both of these indexes, you configure the index up front, and then only
> call index.add(node) to index a node. This will fit in well with the new
> auto-indexing ideas in neo4j.
>
> On Wed, Jun 29,
Recently I have worked on loading the content of DbPedia into my database and
run into a performance issue.
My application has a meta-layer; inspired by the meta model component, but
rewritten in Scala.
All DbPedia resources are said to be an instance of "topic",
creating a relationship from th
ok for it to be based
> > > on n-dim doubles or should be generalized to more types.
> > >
> > > On Tue, Jun 28, 2011 at 11:14 PM, Saikat Kanjilal
> > > wrote:
> > >
> > > > I would be interested in helping out with this, let me know next steps.
>
t Kanjilal wrote:
>
> > I would be interested in helping out with this, let me know next steps.
> >
> > Sent from my iPhone
> >
> > On Jun 28, 2011, at 8:49 AM, Niels Hoogeveen
> > wrote:
> >
> > >
> > > A couple of weeks ago Peter Ne
:
>
> > I would be interested in helping out with this, let me know next steps.
> >
> > Sent from my iPhone
> >
> > On Jun 28, 2011, at 8:49 AM, Niels Hoogeveen
> > wrote:
> >
> > >
> > > A couple of weeks ago Peter Neubauer set up a r
> To: user@lists.neo4j.org
> Subject: Re: [Neo4j] neo4j-graph-collections
>
> I would be interested in helping out with this, let me know next steps.
>
> Sent from my iPhone
>
> On Jun 28, 2011, at 8:49 AM, Niels Hoogeveen
> wrote:
>
> >
> > A couple o
A couple of weeks ago Peter Neubauer set up a repository for in-graph
datastructures: https://github.com/peterneubauer/graph-collections.
At this time of writing only the Btree/Timeline index is part of this
"component".
In my opinion it would be interesting to move the Rtree parts of neo-spati
In 1973, Charles W. Bachman received The Turing Award for his work on
navigational databases, conceptually a cousin of the graph database model.
Here is a link to his Turing Award Lecture:
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=1R6fvsnRfGeFGmTiEjc12H6PYjFQZ_q8yraAcJ32J
x;
> }Yes, but you have to add an intermediate node and then graph becomes
> to be like the 4th normal form in SQL. An artifact to adapt real life
> scenarios to pure and simple technologies. Again an impedance mismatch
> between real life and implementing technology.
> Aniceto
&g
You can create a node type "community-role" with two outgoing relations
"in_community" and "with_role", which respectively point to a "community" and
to a "role". The "user node" can then have a relationship "has_community-role"
pointing to a "community-role" node. Every hypergraph structure c
( e );
> }
> finally
> {
> searcher.closeStrict();
> }
> }
>
> Suffers from the same problem of transactional state and also doesn't
> consider that values could be other types, f.ex. integers where the string
key-object pair. Is this possible? If not with the
current setup, would it be possible to add such functionality? Kind re
gards,Niels Hoogeveen
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.o
(where applicable) for each type we support in the
> >> kernel tests?
> >>
> >> D'oh.
> >>
> >> Jim
> >>
> >>
> >> On 16 Jun 2011, at 23:14, Michael Hunger wrote:
> >>
> >> > Damn, do we have tes
ng values overflow
> >
> > Hi,
> >
> > Try using:
> >
> > http://paste.pocoo.org/
> >
> > Great for sending color formatted code snippets.
> >
> > Marko.
> >
> > http://markorodriguez.com
> >
> > On Jun 16, 2011, at 2:4
i,
>
> Try using:
>
> http://paste.pocoo.org/
>
> Great for sending color formatted code snippets.
>
> Marko.
>
> http://markorodriguez.com
>
> On Jun 16, 2011, at 2:48 PM, Niels Hoogeveen wrote:
>
> >
> > Don't know how to sen
17727 is returned.
Kind regards,Niels Hoogeveen
> From: pd_aficion...@hotmail.com
> To: user@lists.neo4j.org
> Date: Thu, 16 Jun 2011 22:40:24 +0200
> Subject: [Neo4j] storing long values overflow
>
>
> Using neo4j 1.4-SNAPSHOT it seems the storage or retrieval of long
em.out.println(n.getProperty("testvalue2"));
tx.success(); }finally{ tx.finish();
} }}Result:-134217728134217727Kind regards,Niels Hoogeveen
___
that team.
> > What is your github id?
> >
> > Otherwise Niels you're free to fork the repository make whatever changes
> > you want to your fork and then issue pull-requests to Peter.
> >
> > Cheers
> >
> > Michael
hen I did some work on the Meta Model
component. Please let me know if I have to renew that CLA, or if the old one is
still valid.
Kind regards,Niels Hoogeveen
> From: peter.neuba...@neotechnology.com
> Date: Mon, 13 Jun 2011 14:27:32 +0200
> To: user@lists.neo4j.org
> Subject:
together. (see: http://lists.neo4j.org/pipermail/user/2011-May/008461.html)
I hope my suggestion will somehow lead to a solution where the in-graph
Timeline index can become part of the standard Neo4J infrastructure.
Kind regards,
Niels
tion (see:
> http://lists.neo4j.org/pipermail/user/2011-May/008461.html) to move the
> in-graph Btree index and its related classes (including Timeline) to a new
> component Neo4j-collections, while keeping the old Lucene index stuff in
> Neo4j-index,
neo4j.org [mailto:user-boun...@lists.neo4j.org] On
> Behalf Of Niels Hoogeveen
> Sent: Friday, June 03, 2011 2:44 PM
> To: user@lists.neo4j.org
> Subject: [Neo4j] In-graph Timeline index and Neo4j 1.4
>
>
> Today, I tried to migrate my application from Neo4j 1.3 to 1.4M03 and
e index and its related classes (including Timeline) to a new
component Neo4j-collections, while keeping the old Lucene index stuff in
Neo4j-index, so it can eventually become deprecated.
I hope my suggestion will be taken into consideration.
Kind regards,
101 - 200 of 281 matches
Mail list logo
