Oh, confused this thread with store layer changes for type/direction
of relationships. This fruit in this thread is pretty low hanging.

Den lördagen den 6:e augusti 2011 skrev Mattias
Persson<matt...@neotechnology.com>:
> I would not consider this low hanging fruit btw
>
> Den onsdagen den 3:e augusti 2011 skrev Niels
> Hoogeveen<pd_aficion...@hotmail.com>:
>>
>> Hmmm... Does that require the inclusion of golden parachutes as well?
>> Anyway, <addressing the readers of this message that have time allocation 
>> authority>. I hope my suggestion, or another technical solution that solves 
>> the same issues will be picked up for 1.5. This is as far as I can tell 
>> pretty much low hanging fruit. There are probably all sorts of tweaks that 
>> can improve the performance of Neo4j, but this one can improve the 
>> performance of Neo4j big time (under certain conditions). As a user who is 
>> confronted with several very densely connected nodes, I have tried all sorts 
>> of means to solve my issues, but none as rewarding as a solution in core 
>> would be.
>> 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 <pd_aficion...@hotmail.com>
>>>
>>> >
>>> > How does one persuade the time allocation authorities?
>>> > Niels
>>> >
>>> > > Date: Wed, 3 Aug 2011 09:28:45 +0200
>>> > > From: matt...@neotechnology.com
>>> > > To: user@lists.neo4j.org
>>> > > Subject: Re: [Neo4j] Node#getRelationshipTypes
>>> > >
>>> > > Yup, it's a pretty sane approach and somewhat along the lines of how I
>>> > feel
>>> > > it would be done. It's been said a long time that "this functionality
>>> > will
>>> > > be implemented some day" and it's just that a significant amount of time
>>> > > have to be invested... maybe not for implementing it, but for 
>>> > > discovering
>>> > > all bugs and inconveniences 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 <pd_aficion...@hotmail.com>
>>> > >
>>> > > >
>>> > > > I would like to make a suggestion that would both address my feature
>>> > > > request and increase performance of the database.
>>> > > >
>>> > > > Right now the NodeRecord
>>> > (org.neo4j.kernel.impl.nioneo.store.NodeRecord)
>>> > > > contains the ID of the first Relationship, while the 
>>> > > > RelationshipRecord
>>> > > > contain the ID's of the previous and next relationship for both sides
>>> > of the
>>> > > > relationship.
>>> > > >
>>> > > > My suggestion is as follows:
>>> > > >
>>> > > > Create a new store:
>>> > > >
>>> > > > noderelationshiptypestore.db
>>> > > >
>>> > > > The layout of this store is given by the NodeRelationshipTypeRecord:
>>> > > >
>>> > > > id
>>> > > > previousrelationshiptype
>>> > > > nextrelationshiptype
>>> > > > firstrelationship
>>> > > >
>>> > > > The NodeRecord would now need to point to the first outgoing
>>> > > > NodeRelationshipType and to the first incoming NodeRelationshipType
>>> > instead
>>> > > > of to the first Relationship.
>>> > > >
>>> > > > On insert of a Relationship, one side of the relationship will update
>>> > the
>>> > > > store from the outgoing side, the other side will update the store for
>>> > the
>>> > > > incoming side.
>>> > > >
>>> > > > I will list the steps to take here for the outgoing side (the incoming
>>> > side
>>> > > > is almost identical).
>>> > > >
>>> > > > From the NodeReco--
> Mattias Persson, [matt...@neotechnology.com]
> Hacker, Neo Technology
> www.neotechnology.com
>

-- 
Mattias Persson, [matt...@neotechnology.com]
Hacker, Neo Technology
www.neotechnology.com
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to