> The other approach would add an extra row to the topic and article
> table so an article or topic can say it's only a placeholder for
> a symlink. This makes links somewhat heavyweight (after all,
> all fields for the link are meaningless but the link field itself)
> but they can be returned as usual by the _fast routines. After
> a _fast fetch you would still be responsible to check if a topic/
> article is really a symlink and fetch it at that time (and
> check that it indeed exists).
> ....
> placeholders:
> pro: links would be returned for _fast calls
> con: sorting for links would not be reliable for _fast calls (since they'll
> be sorted on the placeholder fields), heavyweight storage-wise. And
> it's definately not the clean approach. Muddles AC.
>
> The sorting problem for the placeholder approach could be 'fixed' by updating
> all placeholders as their target is updated (thereby making them clones
> of their target for all but their children). This would require changes
> in the article fetching and updating functions, and has AC implications.
Making the linking articles clones of the target sounds attractive, but
sometimes
you might want to set some of the fields of the linking and target articles
independently. For example, you could set the score of the linking article
so that it can be sorted in a way that makes sense in another context. I don't
think it presents too much of a management problem to oblige the user to set
these fields up manually (to be either the same as the target or different), in
which case the Midgard functions would only have to ignore the fields in the
linking article that haven't been set.
It might be nice to have a utility to clone the fields used for sorting that the
person
setting up the linking article can use them as defaults.
Paul
--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org
To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]
