mozilla/kuma — pull request #176 by ubernostrum (2012-04-25 17:31:01+00:00)
Title: File migration, part one

Do not merge this :)

So, as part of migrating file attachments from MindTouch, we need to bootstrap a file-storage system in kuma. That's a bit of a job in itself, so I'd like to get some eyeballs on that.

What's in this commit is the utter minimum basics to get that going; a pair of models, Attachment and AttachmentRevision, that mirror Document and Revision in some ways. AttachmentRevision is where the file itself lives, and each Attachment can figure out what its current revision is. There's also a bit of bookkeeping in there, much as with Document/Revision, for migrating stuff from MindTouch.

Some things that are not here:

* A tagging system. If we want one, it'd be easy enough to bolt something on like what we use for reviewing document revisions, but since it wasn't absolutely necessary I didn't do that yet.
* Any sort of view for uploading/managing/viewing files. Mostly that should go in a followup bug.
* Any kind of kumascript integration. It shouldn't be hard to make the necessary data available to kumascript to mimic the MindTouch API for file attachments.

Some questions in need of answering:

* Right now I've got bookkeeping stuff in place to be able to migrate every revision of every attachment, and I'm operating on the assumption that's what we'll do. If that isn't correct -- say, if we're just going to pull the files over and ignore their history -- someone let me know.
* Filename uniqueness is tricky. The method I'm using right now is explained in the comment for the custom upload_to function, but I'm not sure whether it's A) overkill or B) not-enough-kill.
* Attachments and their revisions do not mimic the full API of Documents and their revisions, largely because I don't think most of that API is relevant here. If there's something we think we will need that isn't implemented, let me know and I'll add it.

Also, note that while from a very high-level view this is similar to how MindTouch handled files, it's different in several ways. MindTouch deliberately denormalized a lot more than this does, and I think it denormalized too much (it essentially duplicated the full current revision in the main resource table, for example). This is how I think kuma should be doing things going forward, and the migration script (which will show up later in a different PR) will handle the differences. Everything that MindTouch exposed in its API is, so far as I'm aware, derivable from what this is storing, though.