[development] Lineage module --- nested trees

Earl Miles merlin at logrus.com
Fri Dec 9 16:22:18 UTC 2005


Adrian Rossouw wrote:
> 
> On 09 Dec 2005, at 3:22 AM, Earl Miles wrote:
> 
>> I've gotten, surprisingly, no comments on this at all. Has anyone  
>> looked at this? I need some feedback before I can move forward. I  at 
>> least need to know I'm on the right track.
> 
> 
> My personal opinion is that a generic tree algorithm is less useful  
> than the generic relationship API that has been proposed and is
> being worked on. There are four 'competing' implementations of this  
> API, of which one (ally's hier module) is actually implemented
> as a nested tree in the database (iirc). Your implementation could  
> almost be considered the 5th, albeit lacking in flexibility.
> 
> Trees / Hierarchies are just one type of relationship, and I also  think 
> that caching / persisting trees is probably going to be more  effective
> for a lot of cases, but it will fall apart with _lots_ of data. I am  
> not casting judgement on your code / plans, but I like how Vlado is
> approaching the problem, and thus my support goes to him.

I don't know that the two ideas are really the same.

Everyone I've spoken with about the relationships are very interested in 
creating user-defined relationships and are focusing on a very generic setup.

I think that's great, and I really look forward to seeing what they produce.

That said, all of those implementations seem to be relatively far out. And I 
don't know that they'll actually address the problem this is solving. In fact, 
as a generic API, all of those relationship modules can choose, if they like, to 
utilize this API to improve the sorting results of their relationships, if they 
believe they will gain a benefit from it.

You might say that my implementation is a relationship module that's lacking 
flexibility, but I disagree. It isn't defining, controlling, or even storing 
relationships. That's some other piece of code's job. This one is simply a piece 
of code whose sole purpose is to enhance the performance of existing code.


More information about the development mailing list