At Mon, 13 Dec 1999 09:40:00 +0100, Emiliano Heyns <[EMAIL PROTECTED]>
wrote:
>
>[EMAIL PROTECTED] wrote:
>
>> In addition, topics in the content trees should be able to point to
>topics
>> in the metatrees. (specifying some set of default display data). That
>way,
>> for a simple site, you'd simply set the defaults on a "root" topic
>pointing
>> to the root of the metatree. In addition, you could overide the defaults
>> by normally including the topic.
>
>This would mean I would have to walk the topic tree to fetch an article
>(=expensive), and I wouldn't want the same default publish date, score,
>etc.
>for all articles in the linked topic tree. So each article in the meta
>tree
>would need its own default display data anyway.
>
>> Ie, if you had a topic FOO, which pointed to metatopic FOOa, then
>you could
>> place an article, BAR, which pointed to BARa (an article of FOOa),
> which
>> would ovveride FOO's settings.
>
>So you want to link a topic into a tree, then add articles to the linked
>topic (without disturbing the target)?
>
Pretty much... Mostly I want flexible linking. Such as, for instance, if
I have a forum running off of Midgard, and I store all the data under one
topic. I don't want to have to think about resetting the display related
data for it... so I'll just link the topics, set the content topic to have
some default display information,and be done with it.
>> Hmm.. this is a larger problem. I suppose that you could keep track
>of the
>> last access time, and flag anything that is A) unlinked and B) not
>accessed
>> within X, a user defined time... (by flagging, I mean e-mailing the
>webmaster/owners
>> or having a notice at the root of the admin site... Something like
>this.)
>
>This seems a little to arbitrary to me. I don't want orphaned items
>anywhere. And as I said, per the proposal discussed above (this was
>not your metatree proposal) the article space would be flat, which
>is going to be an access control & maintenance hassle. The hierarchic
>model works well.
Yes... I don't see anyway to prevent orphaned articles, other than some
sort of reference counting... Really, do we -want- to prevent orphaned articles?
It's not necessarily a good thing to kill off hard written content... Probably
be better to make it the administrator's job to decide if something needs
to be deleted.
>
>> That way, if people wanted to keep it, they could. Also, it'd be wonderful
>> if there was some way to archive portions of a site... possibly with
>the
>> option to import it to a -different- site than it was exported from?
>
>Packaging & replication is going to be an integral part of 2.0
Excellent.
>
>> >* (minor) list fetches would require a SQL join, thereby making
>> >the _fast routines not.
>>
>> Ah.... this I do not understand, unfortunately.
>
>A little background: most, if not all, objects within Midgard map
>directly to rows in the MySQL database.
>
>Let's take a simple example: a table article, with fields ID, CONTENT
>and AUTHOR, and a table person, with fields ID and NAME.
>
>*article*:
>(1, 'text', 1), (2, 'more', 2), (3, 'hello', 1), (4, 'world', 1)
>
>*person*:
>(1, 'emile'), (2, 'notemile')
>
>If you want article 4, you just do 'SELECT * FROM article WHERE ID=4;'
>
>Now we want the article + author in on query, so we do
>'SELECT article.ID, article.CONTENT, person.NAME FROM article, person
>WHERE article.AUTHOR = person.ID;'
>
>What the SQL engine will (conceptually, some optimization takes place)
>do is construct a combined table
>(1, 'text', 1, 1, 'emile'),
>(1, 'text', 1, 2, 'notemile'),
>(2, 'more', 2, 1, 'emile),
>(2, 'more', 2, 2, 'notemile'),
>(3, 'hello', 1, 1, 'emile),
>(3, 'hello', 1, 2, 'notemile'),
>(4, 'world', 1, 1, 'emile'),
>(4, 'world', 1, 2, 'notemile')
>
>on which the WHERE query will be applied.
>
>While indeed optimizations are made, JOINs like this affect performance
>more than you'd like. More joins, more memory consumption, more time
>per query.
>
Ah... would not all this information be stored solely in the metatree? That
is, to simply do a author/article lookup, all you need to access is in the
metatree... Of course, with links, you would have to do some checking based
on the link - either the topic that is linked,or the article. If the topic
is linked, simply check for the existence of an article which overides.
The nicest approach for this would be to make the content tree table have
a field ("linkedto", or some such) which would contain the topic/article
number linked to.
When displaying an article which is linked by topic, you then check for
any topic links whose linkedto field matches the article you intend to display.
If the link whose linkedto field is under the topic, then let it override.
Otherwise not. This incurs a small overhead for topic level linking, but
not critically. Optionally provide a script which will autoupdate a topic's
worth of article level links.
Person data would be stored along with the metatree, right?
>The _fast calls do not join in the person data.
>
>> Even so: To speed up searches + such, some caching information could
>be put into
>> the pointer topic/article - the fields could double as the "override"
>fields.
>> Ie, if you need to overide the title, then you simply modify the cached-
>> title field
>
>This pretty much describes how I was going to do the aliases.
Oh?
Sado
IMPORTANT NOTICE: If you are not using HushMail, this message could have been
read easily by the many people who have access to your open personal email messages.
Get your FREE, totally secure email address at http://www.hushmail.com.
--
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]
