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.