Forum OpenACS Q&A: OACS site bboard migration to OACS4

Posted by Roger Williams on 12/16/01 04:17 PM

I saw something somewhere (maybe Musea) about migrating the bboards over to an OACS 4 implementation. I am struggling with some migration issues myself, between beta and production, and I am wondering about the following:

Since topic and message id numbers are generated from a sequence, won't links to bboards posts (within the bboard and outside) be impossible to preserve?
Since authors of bboard posts are stored normalized (i.e. only referencing the uid number), won't author names also be screwed up?

Sorry for the French form of each of these questions, no? I am kicking around multiple unpleasant options to these problems now. I am interested to know how this will be addressed in the production migration of OACS.

Thanks for any help or pointers in advance.

Regards..

2: Response to OACS site bboard migration to OACS4 (response to 1)

Posted by Don Baccus on 12/16/01 08:03 PM

The migration scripts provided for the bboard forum by Musea take care of these problems.

You configure one database pool to point at your old installation. Then you run a series of scripts that pull data from the old installation, massage it, and stuff it into the new installation.

The scripts include one which defines several mapping tables. Using users as an example, a user is pulled from the old installation and created in the new installation. The old user_id and new user_id are added to a mapping table. Then as each forum post is migrated, the old user_id that points to the person who made the post is replaced with the new user_id in the OpenACS 4 installation.

This mapping is done for forums, bboard categories, and messages themselves.

The only thing not done at the moment is to examine each post to see if someone cleverly included a reference to another post via URL. If we want to maintain those someone will need to sit down and write a nice regexp to look for the old URLs, parse out the topic_id and message_id fields, and replace them with the new, mapped versions and the correct OpenACS 4 forum URL.

3: Response to OACS site bboard migration to OACS4 (response to 1)

Posted by Roger Williams on 12/17/01 12:35 PM

Thanks for this info Don. My case is only slightly different in the sense that most of the userid names will have equivalents/be identical in the new system. I was calling making a mapping table that only has use during the conversion, "unpleasant".

Regards..

4: Response to OACS site bboard migration to OACS4 (response to 1)

Posted by MaineBob OConnor on 12/17/01 03:18 PM

I'm a 3x guy and haven't gotten to look closely at OACS4 yet. I did notice that the new bboard urls look like: (for example)

http://openacs.museatech.net/community/forums/message?message_id=5202&forum_id=5110

This looks substantiallly different than the 3x version. It looks like the message_id is all numeric and topic (forum) text has been removed.

It's probably late in the process but I think that it would be more useful to have NO urlvars in the URL and instead have pseudo file names like:

http://openacs.museatech.net/community/forums/message=5204/

...where /message=5204/ is a pseudo file name. This will allow search engines to more easily include threads in their index.

Also, for symplicity, why include the forum_id in the urlvar. This is already stored the the bboard table for each message.

-Bob

5: Response to OACS site bboard migration to OACS4 (response to 1)

Posted by Don Baccus on 12/17/01 05:48 PM

Well, more modern version of the 3.x bboard have an integer topic_id rather than the text topic_id. The fact that the old topic key is still passed around in URLs is an artifact. Some places in the code may still use it but not many.

As far as going to virtual URLs, it is indeed far too late in the process to do such changes. Take heart, though, the bboard datamodel could use a significant overhaul and the code a significant rewrite. If you're volunteering I'll be more than glad to sign you up! I even have the datamodel redesign in mind ...

The current way of handling virtual URLs is pretty gross, IMO. Each package does its own regexp whacking on the tail to figure out which pages to call with each argument, which means you get to decipher each package's .VUH anew when you decide you want to work with it.

It would be nice to have a central mechanism to do the parsing/argument assignment.

You're right that the forum_id isn't needed when processing a specific message.