Slash Boxes
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 ]

brentdax (2147)

  (email not shown publicly)
AOL IM: Brent Dax (Add Buddy, Send Message)

Just another Perl bigot...

Journal of brentdax (2147)

Wednesday July 06, 2005
01:07 AM

Kontent Days 3-4: Storage

[ #25540 ]

Yesterday I started on the basic SQL store, WWW::Kontent::Store::NarrowDBI, and today I finished the reading component of it. Writing will be somewhat harder, because I have three requirements:

  1. In the absence of transactions, a write error must not render a page unreadable; if a page is unwritable, it must be trivial to repair.
  2. In the presence of transactions, a write error must not render a page unreadable or unwritable.
  3. It has to work across most database engines; it can't use engine-specific features, or standard features which aren't widely supported.

One helpful point is that I don't actually want concurrent edits to work; I'd rather have the edit that starts second fail. If Alice and Bob are both revising the same page at the same time, and Alice saves first, Bob should have to examine Alice's edits instead of blindly reverting them.

The name of the store might strike people as a bit odd. NarrowDBI is "narrow" because the attrs table with all of the actual data has only three columnsrevid, name and value. (Alternatives I've imagined are "wide", which has a table with a column for each possible attribute, and "deep", which uses several different tables.)

Basically, each revision has a bunch of attributes, like "content" and "title" and so on. Precisely which attributes a revision has will depend on its class (annoyingly, one of its attributes); the three SQL stores reflect three different ways to organize the attributes.

To save time, I'll only be implementing NarrowDBI for the Summer of Code project. I chose this store for three reasons:

  1. It's the simplest conceptually, given the way the Revision class is defined.
  2. It's the easiest to implement.
  3. It's the only one that allows attribute names to change without altering the tables.

That last point is important, because they are changing; for example, I realized about half an hour ago that DeepDBIand general good designwill require some way to separate different classes' attributes, so I'll be adding prefixes to indicate which part of the system owns the attribute in question. (For example, the revision-wide attributes that were previously called "author" and "date" will now be "kontent:author" and "kontent:date"or maybe "rev:author" and "rev:date", I'll need to think about it.)

Tomorrow, the Revision::revise method, the Page::create method, and the Draft class to go with them.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Please ignore if you've already moved on past this issue. If you've still got this one on the table, maybe the following notes will be of some use...

    If CVS (or whatever) is an option, you can check for conflicts and do a blind merge if no conflicts arrise. If conflicts would occur, you can echo them back to the user and let them resolve before commit.

    That approach may not work for one or more reasons. CVS (or whatever) may not be a prerequisite you want to have for Kontent installation. Merge skills may not