[CDBI] Transactions between HTTP requests?

Ryan Tate lists at ryantate.com
Wed Mar 8 20:12:52 GMT 2006

On 3/8/06, Juan Camacho <jc5826 at gmail.com> wrote:
> For
> example, create a versioning table that contains old values,

I have had some success creating versions within an existing table. I do

my $Package = __PACKAGE__;
__PACKAGE__->has_a( version_of => $Package );
__PACKAGE__->has_many( versions => $Package );

All data lives in one place with one schema, which simplifies life.
version_of always refers to the base version, never to another
version, so you can delete versions at will. This provides a handy
path to undo-ing UPDATEs.

But obviously there is implementational complexity to this, since you
have to filter the table when you list the contents to get exactly
what you want. The nice thing about putting versions in another table
is you don't have to do this.

> or add an
> extra column to tables that indicate the state of the record (review,
> approved, unapproved, etc.).

I also have an is_trashed column. I can "trash" my objects without
confirmation and then "untrash" if I change my mind. Nice way to
provide undo for DELETE-type actions (I prefer the term "trash" so
people have a hint the data Isn't Really Gone Yet).

This adds yet more implementational complexity, usually just one extra
condition in the SQL, but this can limit your ability to use built in
CDBI methods. The bigger dillemma was how (and whether) to integrate
this with my full text search store.

With version_of and is_trashed, I get the ability to undo update and
delete operations, at significant cost. Insert is obviously easy to
undo without such hoops ;-> Despite the price, it is very satisfying
to be able to offer Undo. Very user friendly.

More information about the ClassDBI mailing list