err, lol, actually I failed here, it was actually two primary databases, I only used primary+secondary databases when storing String->longID 1-to1 mapping that is, when emulating a HashMap by using berkeleydb where each side(key or value) can be connected to only one other thing (value or key) but when allowing 1-to-many, must use two primary databases; ok, I stand corrected ;) sorry
John. On Fri, Jul 29, 2011 at 6:53 AM, John cyuczieekc <[email protected]>wrote: > small obvious correction btw, it's not 2 primary databases, it's 1 primary > and 1 secondary ;) my bad > > > On Fri, Jul 29, 2011 at 6:49 AM, John cyuczieekc <[email protected]>wrote: > >> Hi xD >> I'm not clear what you need to store here, if I understand correctly you >> could store in 2 primary bdb databases the nodeID (ie. long) of each node in >> a relationship >> ie. >> key->value >> >> dbForward: >> A->B >> A->C >> X->D >> X->B >> >> dbBackward: >> B->A >> B->X >> C->A >> D->X >> >> A,B,C,D,X are all nodeIDs ie. longs >> >> this way you could check if A->B exists, or all of A's endNodes , or what >> startNodes are "pointing" to the endNode B >> the storing of these would be sorted and in BTree, lookup would be fast, >> so you can consider ie. A as being a set of B and C, and X being a set of B >> and D, (that is you cannot set the order as in a list, they are sorted by >> bdb for fast retrievals). (But upon this, sets, can build lists np - that is >> using only bdb; tho you won't need that using neo4j) >> So, if this is the kind of index you wanted... (I am not aware of specific >> indexes with bdb, though that doesn't mean they don't exist) >> >> Insertions would require transaction protection so both A->B in dbForward >> and B->A in dbBackward are inserted atomically. 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 < >> [email protected]> wrote: >> >>> >>> Thank you, Peter,There is no rush here. It would be nice to investigate >>> this option, but it can wait until Mattias has returned and sifted through >>> urgent matters. The question is even, if it would be a good idea to use an >>> index to do the book keeping for Enhanced API.As it is now, the Reification >>> of eg. a Relationship, requires one property to be set on a relationship, >>> containing the node ID of the associated node. On the associated node is a >>> property containing the ID of the relationship, so there is a bidirectional >>> look up. Introducing an index would remove the need to have these additional >>> properties, but would lead to slower look-up times (no matter how fast the >>> index).So it's a trade-off between speed and cleanliness of namespace. Using >>> the Enhanced API disallows certain property names to be used in user >>> applications.The property names used in Enhanced API all start with >>> "org.neo4j.collections.graphbd.", so there is little chance a user >>> application would want to use those property names, but it is a restriction >>> not found in the standard API, so ultimately something to consider.Niels >>> > From: [email protected] >>> > Date: Thu, 28 Jul 2011 10:39:47 -0700 >>> > To: [email protected] >>> > Subject: Re: [Neo4j] bdb-index >>> > >>> > niels, >>> > in this spike, I just concentrated on getting _something_ working in >>> > order to test insertion speed. This is not up to real indexing >>> > standards, so some love is needed here. I think Mattias is the best >>> > person to ask about pointers, let's wait until he is back next week if >>> > that is ok? Maybe some other (like the standard Lucene) index can >>> > suffice for the time being to test out things? >>> > >>> > Cheers, >>> > >>> > /peter neubauer >>> > >>> > GTalk: neubauer.peter >>> > Skype peter.neubauer >>> > Phone +46 704 106975 >>> > LinkedIn http://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 coolest Bring-a-Thing >>> party. >>> > >>> > >>> > >>> > On Thu, Jul 28, 2011 at 10:36 AM, Niels Hoogeveen >>> > <[email protected]> wrote: >>> > > >>> > > 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 retrieved indexName >>> is not actually garbage. I would like to help make this component workable, >>> but area of the database is a bit beyond the scope that I know. >>> > > I know this is completely unsupported software, but can someone give >>> me some pointers on how to fix this issue? >>> > > Niels >>> > > _______________________________________________ >>> > > Neo4j mailing list >>> > > [email protected] >>> > > https://lists.neo4j.org/mailman/listinfo/user >>> > > >>> > _______________________________________________ >>> > Neo4j mailing list >>> > [email protected] >>> > https://lists.neo4j.org/mailman/listinfo/user >>> >>> _______________________________________________ >>> Neo4j mailing list >>> [email protected] >>> https://lists.neo4j.org/mailman/listinfo/user >>> >> >> > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
