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

[Sam T. <sa...@tr...>]

On Tue, 19 Apr 2005, Christopher Hicks wrote:

> 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.

Why do this work when (exactly) the data you want is already in the
story_version table?  You can just move the records over which should
be very fast.

> - 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.

I think that makes sense.  I see no reason undelete() couldn't be
written to keep the story_id in place.

> - 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.

It doesn't.  In particular, it doesn't store the version history of a
story.  Also, the XML system is designed to work exclusively with
Krang::DataSet to produce comprehensive KDS files with no dangling
dependencies.  I don't think that makes sense for this system.

Krang supports two serialization systems (Storable and XML) because it
has two very different use-cases for serialization.  Versioning
serialization (Storable) has to be fast and compact.  It doesn't have
to deal with dependencies in any particularly smart way.  XML
serialization has to be human readable and smart about dependencies.
It doesn't need to be particularly fast or compact.  I think your
undelete system is closer to the versioning use-case than
import/export.

> - there are already two serialization methods in Krang::Story, with
> the XML version being the only one that actually works.

Is revert() broken for you?  It works for me...

> Doing what I'm doing now will create yet a third path that is
> essentially accomplishing the same thing.

It shouldn't.  I see no reason you can't just use the data in
story_version.

-sam