[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Debian-sf-devel] Future functionality questions...

From: Tim Uckun
Subject: Re: [Debian-sf-devel] Future functionality questions...
Date: Thu, 27 Dec 2001 12:29:35 -0700

Here's a use case description of the improved foundry system might be used
and how it might be useful to you.  (I agree that task tracking is something
I would love to see handled better, too! )

Very interesting. I have been thinking about this for a long time and the conclusion I came to was this. What is REALLY needed are two things. A generic hierarchical object and a generic symlink object. The hierarchy stores symlinks. Each object has a unique ID (OID or a serial). The symlink is what is stored in the hierarchy. Each hierarchy is nothing but a table containing the leaf nodes and the symlink. I was thinking about coding up the examples in the "SQL for smarties" book by Joe Celko.

My thinking goes like this.

All things have a context. Users, departments, documents, discussions, bugs, feature requests etc. All of these are usually expressed as a hierarchy. If you could coneniently ask questions about the object like (list all parents, list all children, reparent this object etc) then everything else falls into place easily. No need to try and warp metaphors. Instead of saying "a foundry is like a dept" you simply create a new table (hiearchy) and call it a dept. The dept could be sub dept of anything. It could contain members (another table = another hierarchy) etc.

I don't know if I am making myself very clear but if you look at SF you will see that it contains nothing but hierarchies. It seems to me if we attacked that core everything else would fall into place including complex ACL types of systems.

Tim Uckun
US Investigations Services/Due Diligence

reply via email to

[Prev in Thread] Current Thread [Next in Thread]