[Neo] Fwd: Performance question

[Atle Prange]

The first draft i have implemented is the wrapper approach:

Entities must subclass NodeWrapper, and typed relations RelationshipWrapper.
These superclasses can get a context set on them, which contains the graph
element they wrap.

I added some helper classes that makes the setting and getting of properties
and relations type safe and less error-prone, but i no longer have my normal
fieldsin my class:

class Person extends NodeWrapper{

    private Value<String> name = Values.property(this,String.class);

    public void setName(String newName){
        name.set(newName);
    }

}


I have the same thing with relations; special classes that entites can use
to express the relations.

I don't like it though, it doesn't "feel right". It makes my entity very
connected to the persistence implementation, i will have to investigate
further, and simplify stuff a bit.

A very interesting sideeffect of using Neo4j as a back-end is its capability
as a RelationshipManager [1]. This is nothing new to you graph-database
guys, but in standard OO, this idea is worth digging into.

If i don't want to pursue the subclass pattern, i have three options left:

1) load/store, which already has been implemented (almost twice).

2) Bytecode manipulation (runtime weaving is hard in felix, therefore i am
stuck with build-time weaving, like Apache Cayenne)

3) Proxying. With this option i have to tell some handler what to store back
to the node when an method is called.
It could look like this:

class Person{

    private String name;

    @Converter(InstantConverter.class)
    private Instant instantOfBirth;

    @Sideffect({"name"})
    public void setName(String newName){
        this.name = newName;
    }

    @Sideffect({"name","instantOfBirth"})
    public void setNameAndInstantOfBirth(String newName,Instant
instantOfBirth){
        this.name = newName;
        this.instantOfBirth = instantOfBirth;
    }


}



Sorry if i am boring you guys, but i think neo4j is the way to go on
persistence...

-atle



[1] http://code.google.com/p/relationship-manager/wiki/PageName






On Wed, Apr 21, 2010 at 3:57 PM, Tobias Ivarsson <
tobias.ivarsson at neotechnology.com> wrote:

> On Wed, Apr 21, 2010 at 2:56 PM, Atle Prange <atle.prange at gmail.com>
> wrote:
>
> > I got the same thing:
> >
> > Here is my answer to your post:
> >
> >
> >        I agree with you completely, and i am trying to get the best of
> >        both worlds. Maybe bytecode manipulation is the only way to
> >        go....
> >
> >        But are you in fact saying that i am implementing an
> >        antipattern, and both jo4neo and neo-persistence use the same
> >        antipattern?
> >
> >
> I assume the pattern you are referring to is the load/store pattern. I
> wouldn't say that it is an anti-pattern, for neo-persistence (worst name
> ever) it is a very valid pattern, since the goal of that component is to
> implement the Java Persistence API (JPA) on Neo4j. For jo4neo it's the way
> it needs to be done because of the way it wants to represent state.
>
> However, the delegating software transactional memory object mapping model
> that we advocate for representing objects, that Anders mentioned earlier in
> this thread, gives you good performance and is easy and convenient to work
> with. It would be interesting if you could take that approach instead,
> since
> jo4neo already fulfills the load/store usecase, but if you have ideas that
> will make your load/store based system better than jo4neo in some aspect, I
> don't want to get in your way, I think you should explore those ideas. I am
> looking forward to hearing about your results.
>
>
> >
> >        A related question on performance. When fetching relations from
> >        a node using Node.getRelatioships(RelationshipType...types), is
> >        the node loading all relationships, and the collecting all of
> >        the given types, or are just the matching relationships loaded?
> >
>
> With the current implementation the answer is "something inbetween", Neo4j
> will look at relationships of more types, but only the ones of the
> specified
> types are actually loaded. This will change in an upcoming version to only
> look at the relationships of the actual specified types.
>
> Cheers,
> --
> Tobias Ivarsson <tobias.ivarsson at neotechnology.com>
> Hacker, Neo Technology
> www.neotechnology.com
> Cellphone: +46 706 534857
> _______________________________________________
> Neo mailing list
> User at lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>