freshcode.club currently uses SQLite (and the VCS just so happens to be sqlite-based fossil). That seems entirely sufficient for the prototype, for mirror sites, possibly even for the foreseeable future. (FM had, if I may say so, a peewee database of just 20MB.)
The scheme is almost self-explanatory. Most submission fields end up in their according column:
CREATE TABLE [release] ( -- General project description [name] VARCHAR (100) NOT NULL, [title] TEXT NOT NULL, [summary] VARCHAR (160), [homepage] TEXT, [description] TEXT NOT NULL, [license] VARCHAR (100), [tags] VARCHAR (200), [image] TEXT, -- Per-release entries [version] VARCHAR (100) NOT NULL, [state] VARCHAR (20), [scope] VARCHAR (20), [changes] TEXT, [download] TEXT, [urls] TEXT, [submitter] VARCHAR (0, 50), [submitter_image] TEXT, [submitter_openid] TEXT, -- Autoupdate fields [autoupdate_module] VARCHAR (20), [autoupdate_url] TEXT, [autoupdate_regex] TEXT, [autoupdate_delay] FLOAT, -- Control meta [t_published] INT, [t_changed] INT, [flag] INT DEFAULT(0), [deleted] BOOLEAN DEFAULT(0), [hidden] BOOLEAN DEFAULT(0), [lock] TEXT, [via] TEXT, -- "form" or "api" or "autoupdate" [social_links] INT, -- counter [editor_note] TEXT, -- custom notification to submitter -- Scheme CONSTRAINT 'release_revisions' UNIQUE ( name, version COLLATE 'NOCASE', t_published, t_changed ) );
One interesting point is that this database scheme is implicitly versioned. The
t_published timestamp notes the first time a
version release got added. While subsequent
t_changed entrys add revisions onto each
Originally I also planned to separate general project and release data into two tables. But it's much simpler to manage this way. And implicitly revisions the general project infos along. Which is another reason we don't need a full moderation system; there's always a full history anyway.