Hi James,
> > > I've chosen to use the print field in the article table to store the id
> > > of the location topic of the article and the extra1 field to hold the
> > > secondary topic for that article. It just occurred to me that if I have
> > > topic ids in these fields, then if the site is replicated, it won't work
> > > if the topic ids of the topics change in the new replication version.
> > > But then topic ids are stored in the topic field of the article table.
> > > Does repligard go through an change all the ids of everthing based on
> > > GUIDs including changing the topic ids in the articles table and the
> > > object ids in the blobs table? Does it follow that if I want to relate
> > > articles to more than one topic, a better way would be to store the
> > > GUIDs of the related topics in the extra fields of the articles table?
> > >
> > Both yes and no. You probably want to use parameters for this. Check out
> > the manual for more information.
> I wanted to use the articles table because I'm using direct MySQL
> select queries to select articles. I couldn't see how I could get
> midgard to do something like this:
> $sql = "select id, title, name, extra1, topic, abstract, url,
> created as created from article where ";
> $sql .= "(topic in ($topic_ids_in_tree) or ";
> $sql .= "extra1 in ($topic_ids_in_tree) or print = $location_id)
> and ";
> $sql .= "(date_add(created, interval 6 month) > now()) and ";
> $sql .= "sitegroup = " . $midgard->sitegroup;
> $sql .= " and type=3 order by created desc";
> I needed to be able to sort by primary topic (topic), secondary topic
> (extra1) and physical location (print) and document type (type).
> So an article might have:
> primary topic - Forests
> secondary topic - corporate campaign
> location - New South Wales
>
> Different parts of the site display different sets of articles based
> on these parameters. I couldn't see how to achieve this flexibility
> using Midgard parameters.
Err. my point was : Store topic GUIDs in the parameters.
How do you structure the topics, I got this for Nature and Youth norway
(www.nu.no):
energy
-> nuclear
-> climatechange
-> oil exploration
-> Kyoto
Then you could define a search where you start with something like
this:
$article = mgd_get_article($id);
$primtop = $article->topic;
$articles = mgd_list_articles_all($primtop);
$topic = mgd_get_topic($primtop);
while ($articles->fetch()) {
// show article
$sectop = $mgd_list_topics_all($sectop->up);
while (..) {} ..
}
tarjei
> But even if I saved these additional article attributes in the
> parameters table, I would still have the same problem with repligard
> because the topic ids would be saved as 'hard' values. So I guess my
> question remains: If topic ids are also stored in places in addition
> to the normal topic fields, then does that render the app repligard
> unsafe?
>
> Our live site and staging site appear to use the same article and
> topic ids. Does repligard try to use the same id and only create a
> new one if it is already being used in the destination database?
>
> Thanks
> James
> > Btw, what about the articles topicfield? What is the difference between
> > the location topic and the topic the article is stored under?
> >
> > tarjei
> >
> >
> >
> > > Thanks
> > > James
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
