[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)?
> 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.
> 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
> >* (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.
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.
Bye,
Emile
--
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]
