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:
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:
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.
sensitive handling of concurrent edit attempts (Score:2)
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