Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of Kake (3534)

Sunday January 05, 2003
06:54 PM

Backwards (in)compatibility

[ #9782 ]

I should have known this was going to bite me in the arse at some point. I needed to add another table to the database schema for CGI::Wiki, to store details of which nodes link to other nodes, so we can do backlinks properly (ie, find out all nodes which link to a given node).

This means anyone upgrading from a pre-0.15 version needs to re-run the setup script on their database, so they have the extra table. If they don't, then their code will complain and die when they try to run it on an existing database.

Unfortunately the setup scripts distributed with pre-0.15 versions of CGI::Wiki have the nasty side-effect of deleting all your data if run on a pre-existing database. This is fixed in 0.15, but it means you really have to be sure which versions of the modules you're running the scripts with, if you're trying to fix up your existing database to work with the latest CGI::Wiki.

This is documented in README, INSTALL, Changes and the pod of Wiki.pm — I hope that's going to save anyone from getting annoyed with me.

On the bright side, we do get real backlinks, which is very cool (blair christensen's idea so thank him if you like it).

This links in to something I've been worrying about for a while — how do you pick the right balance between:

  • releasing early enough that people can use what you're doing, avoid reinventing wheels, and give you good ideas
  • not releasing so early that you have an absolute nightmare trying to keep backwards compatibility when you add new features that you didn't have time to get in before your first public release

The first release of CGI::Wiki took two months to escape from when I first thought of it, and I purposely delayed it until I'd decided how I was going to put version information in the tables. I hadn't even thought of backlinks at that point; it was only after I released it and blair mailed me that I realised they'd be useful. So even if I had delayed it longer, I'd still have the backwards compatibility problem now.

I'm actually less worried about changing the database schema than I am about changing the interface. At some point soon I'm going to start adding the capability to store metadata about the nodes, and right now I'm really feeling that the nodes should have been objects. Which one's neater:

$node = $wiki->retrieve_node("Penderel's Oak");
$node->add_metadata( type => "Categories", data => "Holborn" );
$node->write;

or

%node_data = $wiki->retrieve_node("Penderel's Oak");
$wiki->write_node("Penderel's Oak", $node_data{content}, $node_data{checksum}, { type => "Categories", data => "Holborn");

Now guess which one I've saddled myself with.

However, reasons to be cheerful:

Current to-do list:

  • Get phrase searching working with Search::InvertedIndex
  • Look at the code Roger sent me ages ago (sorry Roger, I'm slack)
  • Release CGI::Wiki::Formatter::Usemod
  • Think about that damned metadata problem
  • Write CGI::Wiki::Formatter::Pod
  • Get my head round Jo's RDF/grubstreet ideas
  • (very speculative) Think more on the recipe DTD/semantic web stuff I was talking about with Earle
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Yes, I think wiki's are pretty sexy. The reason I've got completely separate Wiki modules is that Text::WikiFormat is slightly designed to allow overriding the output, but it doesn't go far enough. It's still very much designed to take Wiki text as a string and output a string. If on the other hand you adopted the SAX model, your input can be a string, a file or a filehandle, and the output is a data format (which you can then turn into a string or HTML if you so wish). I need that flexibility to be able to
    • Matts wrote:

      The other thing about the AxKit wiki is that you can author pages in POD, which I find very sexy indeed. POD isn't the world's best format, but it's actually really well suited to Wikis.

      Now look what you made me do [penseroso.com].

      I must look into AxKit at some point. I seem to have the idea that it'll all be too complicated for me to grasp, though this may or may not have any relation to reality.