[development] Lineage module --- nested trees
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