[Krang-general] deleting stories, bad bad bad -- lets agree on how to fix it

[Christopher H. <ch...@ch...>]

On Fri, 1 Apr 2005, Sam Tregar wrote:

> Yes.  One of the best reasons to delete a story from a website is that 
> you no longer have a legal write to the copy.  This can occur when a 
> magazine purchaces the rights to a story for a limited period of time, 
> as is common with newsfeeds, or when the magazine never had the rights 
> in the first place.

I understand this is a need that should be dealt with.  But I strongly 
feel that having a consistant "its safe to make changes, because nothing 
is irreversible" makes a lot more sense and is much more consistant than 
"its safe to make changes because they're reversible unless you click this 
on particular button which is only reversible if you haven't made any 
changes today and your sysadmin has hour to blow to recover the story from 
backup".

> A secondary reason is to keep the database from growing without limit. 
> The bigger the database gets the slower it runs, so deleteing old 
> content is a good way to keep it running fast.  If the system won't (or 
> can't) actually delete content then this won't work.

Since we're talking about moving deleted stories to a whole different 
table I can't see that it would have any impact on krang's normal 
performance.

> Fortunately, Krang has a very easy to use backup and restore system.

If you're willing to go back in time it may be easy.  If you're 
selectively recovering a single story it require bringing up a temporary 
instance of krang to extract that story and recover it.  This is hardly 
trivial or easy.

I was asked to propose a schema for a more practically recoverable delete 
and here it is:

mysql> describe story_deleted;
+----------+------------------+------+-----+---------+-------+
| Field    | Type             | Null | Key | Default | Extra |
+----------+------------------+------+-----+---------+-------+
| story_id | int(10) unsigned |      | PRI | 0       |       |
| data     | longtext         |      |     |         |       |
+----------+------------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

The idea would be that all of the stories versions would be serialized 
into a Perl array and then put into the database using Storable.

I've actually gotten this partially working now.  This has led to a few 
other ideas and issues:

- to make this clean it would be best to have the story_id remain the 
same.  This would minimize broken link issues and allow for repeated 
deletions and recoveries.

- much of the necessary functionality to do this already exists in the XML 
serialization functions, but they create a new story_id, the XML is much 
larger, and I'm not sure that the XML encodes everything that is actually 
in a story.

- there are already two serialization methods in Krang::Story, with the 
XML version being the only one that actually works.  Doing what I'm doing 
now will create yet a third path that is essentially accomplishing the 
same thing.  Some refactoring seems to be in order to reduce duplicate 
code paths and make maintenance easier.  Ideally I would like to see a 
Krang::Story object be able to be created and then repopulate itself in 
the database.

Sam proposed in a private email that the datastructure for the 
story_deleted table be something more along the lines of

+----------+------------------+------+-----+---------+-------+
| Field    | Type             | Null | Key | Default | Extra |
+----------+------------------+------+-----+---------+-------+
| story_id | int(10) unsigned |      | PRI | 0       |       |
| version  | int(10)          |      |     | 0       |       |
| data     | longtext         |      |     |         |       |
+----------+------------------+------+-----+---------+-------+

While this would accomplish the same thing as what I've proposed above I 
don't see that splitting this up at the database level accomplishes 
anything of value.

-- 
</chris>

"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)