Forum OpenACS Q&A: Editing a topic name?
This is probably a simplistic question, so apologies; but help will be appreciated. I'm running OpenACS 3.2.5. I have a BBoard topic where I would like to change the topic name. This is not a big deal, but is just something I'm using to poke into ACS and try to understand it a little better. bboard/admin tells me, interalia, that: Things that you can't do (well, not from here) you cannot change the topic name because it is used as a database key in the bboard messages table So I'm just trying to why this is so (or how I could get around it if I really wanted to). I've looked at the data model in: doc/sql/bboard.sql I can see the topic name field in bboard_topics; but I can't see it referenced in table bboard (the "bboard messages table" referred to above?). So: if I just manually went into bboard_topics and changed a topic name, what would actually go horribly wrong? Thanks,
In modern Oracle and PG it doesn't make much of a difference as both support "on update cascade", which would change the key values automatically, but when Philip wrote it for Illustra that wasn't true and the code would've been a bit tricky to write.
Anyway, if you go to the topic and see the messages there you're in fine shape.
You Wrote: "So: if I just manually went into bboard_topics and changed a topic name, what would actually go horribly wrong?"
My experience is NOTHING would go wrong... I've changed the topic name without anything "bad" happening. I've also manually the subject name, and occasionally the message. -Bob
If someone wants to prepare a patch and submit it to the SDM I'm sure Roberto would be thrilled to include it in 3.2.6 ...
gone ahead with manually changing the topic name and it seems to
I just applied it here locally, and very brief testing shows that it works. I'll play slightly more, and then submit to the SDM. In essence, my patch just removes the topic variable from several calls to export_url_vars in three utility procs within tcl/bboard-defs.tcl, the main one being bboard_msg_url.
It works for me! A few of the bboard admin pages still end up with topic in their URLs, but this fixes all URLs that point to actual bboard messages, which are the ones most often used, linked to, etc.
Don wrote: "Yes, the topic doen't need to be in the URL any more, just the topic_id."
Actually, only the message ID is needed because the topic_id is a field table bboard and therefore if you need it, go get it!
will bring you back to this thread!
THis brings up another point which I havn't solved.... I use within page references to the latest post within a thread using the # ...#0002Tp It turns out that # references are case insensitive and occasionally messages like 0002Tp get confused with 0002tP etc...
Bob> THis brings up another point which I havn't solved.... I use Bob> within page references to the latest post within a thread Bob> using the # ...#0002Tp It turns out that # references are Bob> case insensitive and occasionally messages like 0002Tp get Bob> confused with 0002tP etc... Co-incidentally I hit this same issue in a completely different context today (not involving ACS at all) so I set off to check out what the situation is supposed to be. The HTML (4.01) spec is completely clear: both the name and id attributes are specified as being case sensitive - so any browser which confused them in the way you indicate above is *broken*. Not that that is necessarily much comfort, but if does mean that if you invest effort working around such a problem it could be undermined at any moment when the browser developer fixes the bug... Now for what it is worth, my problem was precisely opposite: I had a page where the internal links *failed* to work precisely because they had case differences and my browser (Netscape 4.x on Linux) *correctly* regarded them as distinct. But this strongly suggests that the author of the page has a browser which behaves in the opposite way (case insensitive). The obvious suspect would be Internet Explorer - can anyone check this one way or the other? - B.
This would reduce the theoretical maximum bboard messages per ACS instance from 56800235584 to a mere 2176782336... but who has an ACS site that needs to store more than 2 billion bboard messages anyway??
I *know* ACS is/was designed for scalability, but surely allowing for 56 billion bboard msgs per ACS instance was slight overkill!?
I think that moving to base 36 for new installations (hard to convert existing ones well, links would get broken) might make some sense.
Switching to base 36 for a new installation would be a trivial patch, just deleting a few lines from proc increment_char_digit would do it.
If anyone really needs to handle tens of billions of bboard messages, and avoid this case issue, moving to a 7 digit (base 36) msg_id would be one way to do so!
I'm not going to attempt the zero stripping and filling idea, it saves so few chars anyway... but that shouldn't stop someone who really wants it from hacking it in and submitting the patch.
Note: this patch is tested a little on Q&A format bboards, and not tested at all on other formats of bboard.
name in the bboard_topics table: this is not automatically
reflected in the names (long and short) of the corresponding
administration user group (in the user_groups table). So I just
fixed them up too (which I *can* do through the admin web
interface rather having to manually hack the database).