Best practices for autosaving drafts?

Question

What is the best strategy for applications that autosave an email before it is sent or save a blog post before it's finished or officially saved? Would it be best to use a separate table in the database for temporary drafts or to have a status column that marks a post as draft or published? I'm not looking for code, just methods, but any other related advice would be welcome as well, like how often to save, etc.

Answer 1

Considering that separate tables for drafts and published articles would be essentially duplicates of each other, I would lean towards just one table with a status column to differentiate between the two.

Answer 2

I do drafting on the Wikipedia way: I save the first version, and all modification's saved (based on time or explicit user command) as a next version. After ie. publication you can delete the draft-graph - or not.

If you save data in database I think it's good to use the same table (you can avoid schema conflicts), and use version/status to track drafts lifecycle.

Answer 3

this applies to more than emails...

I changed my mind on this one. The best way is to use a is_draft column in your table and store both drafts and valid entities in the same table. this has the advantage of the entity keeping the same id even if it switches in and out of draft state (you might want to edit it after you save it, but temporarily remove a required value). it would be confusing for users if they were collaborating on the same document and the id kept changing, amirite?

you would use is_draft=1 to turn off ORM validation rules, trigger validations or check constraints to allow an invalid object to save. yes, you'd likely have to allow nullable fields in your table.

process: try to save object. validation fails. set is_draft=1 and try to save again. it saves. put big "DRAFT" on the screen somewhere :)

user fills in required info. try to save object. validation passes. set is_draft=0. it saves.

now, regarding email and blog posts, your server shouldn't try to send it or post it right away unless the user hits the save/post button, but that is a different issue really.

---

OLD ANSWER

The problem is that a draft might not be valid, and cannot be saved in the actual table. For example, say your table demands that the subject be not null, but the user hasn't filled it in yet.

One way would be to have a draft table, and store a serialized version of the entity (and its children) to it. php's serialize() would be something to use, or you could use json. when it is finally valid, the system would save instead to the email (or whatever) table, and delete the draft:

pseudo sql:

create table draft  
id int primary key auto increment,  
entity varchar(64) not null comment 'this way you can find all drafts of say type Email',  
contents longblob not null,  
modified timestamp comment 'this way you can sort by newer drafts'  
modified_by int not null foreign key to user.id comment 'this way you can filter by the user\'s drafts'

you could also consider a draft_file table for storing attachments or photos for the draft, and be able to access them individually:

create table draft_file  
id int primary key auto increment,   
draft_id int not null foreign key to draft.id on delete cascade,  
size int not null comment 'bytes',  
mime_type varchar(64) not null,  
file_name varchar(255) not null,  
contents longblob,  
thumbnail blob comment 'this could be an icon for files/documents' 

so, a user starts composing an email, maybe just types in the body, and adds some attachments. your gui saves the email to drafts, and uploads the attachments, saves them to draft_file, and returns the draft id, and the download urls for the files which you display in your gui.

he types in the Subject (To is still blank). Your gui saves the email to drafts, updating the draft table by id, as it knows its id from the previous step.

your users fills in the To field, and hits Send. Your server saves the email to the email table, copies the attachments from draft_file to the email_attachment table, and deletes the draft, preferably within a transaction.

this allows for long-term drafts, gmail-style attachment uploads, while maintaining integrity of your real entity table.