Hi Peter,
I totally agree, however as it now stands, there is a mutual dependency between
the two.
IndexedRelationships contains some code using PropertyTypes to make comparison
between indexed nodes possible based upon a property. PropertyType contains the
comparator object needed for that. That particular functionality will need to
be stripped out of IndexedRelationships. No big deal, since it is already
covered in SuperGraph API (TM) :-)
In the mean time I am doing some experiments in Scala with a new approach to
the API, where the database is treated as if it were a key-value store. Every
element of the store supports polymorphic get, put and remove methods and with
each call a typed key object is supplied to dispatch on the right method.
I'll give you example of how that will look:
Suppose we have two people "John" (age 40) and "Peter" (age 42) who are friends.
First we fetch some keys for the properties and the relationship
val name = Store.get(StringValue, "name")
val age = Store.get(IntValue, "age")
val friend = Store.get(VertexOut, "friend")
now we create the two persons:
val john = Store.get(NewVertex).put(name, "john").put(age, 40)
val pete = Store.get(NewVertex).put(name, "pete").put(age, 42).put(friend,
john)
We can fetch John's name by calling:
john.get(name)
and we can fetch his friends by calling:
val friends = Store.get(Vertices, "friend")
john.get(friends)
Suppose we want to state that John gave Pete a book, yesterday, we can do that
as follows:
val giver = Store.get(Role, "giver")
val recipient = Store.get(Role, "recipient")
val gift = Store.get(Role, "gift")
val when = Store.get(Role, "when")
val edge = Store
.get(NewEdge, "GIVES")
.put(giver, john)
.put(recipient, pete)
.put(gift, Store.get(NewVertex)
.put(name, "book"))
.put(when, StringRole, "yesterday")
Note that the Edge in this case not only connects to Vertices (john, pete and
book), but also to a property on the Edge itself (yesterday).
Both Vertex and Edge have no logic of there own. Every get or put is dispatched
to the supplied Key object. This way the implementation becomes completely
pluggable. Suppose we want to introduce a PropertyType that does not fetch data
from the store, but performs some calculation, it is not necessary to change
the Vertex implementation. We just provide a key with the right signature and
the dispatch mechanism makes sure that the call is made on this new
PropertyType.
The keys can be as simple as denoting a property or a relationship, but can
also be as complex as a complete traversal description.
I will provide a Java wrapper, so this API can both be used from Scala and from
Java.
Niels
> From: [email protected]
> Date: Tue, 23 Aug 2011 14:59:09 +0200
> To: [email protected]
> Subject: Re: [Neo4j] Enhanced API rewrite
>
> Niels,
> I think the SuperGraph API (TM) should go into its own component and
> then depend on the collections component. I can prepare that and maybe
> move the code there during the week or next? This way, we can evolve
> the API apart from the more pragmatic collection component.
>
> WDYT?
>
> 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 Mon, Aug 8, 2011 at 9:58 PM, Niels Hoogeveen
> <[email protected]> wrote:
> >
> > Hi Dmitri,
> > I would very much appreciate it if you tried out Enhanced API and gave me
> > feed back about your findings. Apart from traversals it is more or less
> > feature complete, but it could use some thorough trying out.
> > Niels
> >
> >> Date: Mon, 8 Aug 2011 20:20:14 +0500
> >> From: [email protected]
> >> To: [email protected]
> >> Subject: Re: [Neo4j] Enhanced API rewrite
> >>
> >> I ready to jump in too ;-)
> >>
> >> On Mon, Aug 8, 2011 at 3:37 PM, Niels Hoogeveen
> >> <[email protected]>wrote:
> >>
> >> >
> >> > I can probably find the time for that. It would be fun working on these
> >> > ideas in collaboration. I don't mind producing my usual brain-dumps and
> >> > write some of the code, but quality will certainly improve when it is
> >> > more
> >> > than just me paying attention to this.
> >> > Niels
> >> >
> >>
> >>
> >> --
> >> Dmitriy Shabanov
> >> _______________________________________________
> >> 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
