[jifty-devel] JDBI transactions

[Andrew Sterling Hanenkamp]

Actually, I disagree on two counts:

 1. I was thinking of implementing this in a completely separate
module---there is no general-purpose transaction module on CPAN that
I've been able to find. This means a minimum of bloat to Jifty because
it would just use the system.

 2. Any truly robust transaction system should be able to work even when
underlying systems fail to implement them. I was thinking of employing
such a framework.

It may not truly provide the completely reliable transactions (i.e.,
those that really provide atomicity, consistency, isolation, and
durability) without some low-level functionality added to cope with the
specific instances, such as my DBD::CSV example. However, I think that
having the capability as part of Jifty (and available to the greater
CPAN community in a general module) is an excellent idea.

However, with each comment in this discussion, my intent seems to
expand, so perhaps I will just implement it in a small way that handles
the initial needs of the virtual-models branch and perhaps the deferred
write idea for sets and look at the bigger implementation as an ongoing
project.


--
Andrew Sterling Hanenkamp
Interaction Developer
Boomer Consulting, Inc.
 
1.785.537.2358 ext. 17
1.888.266.6375 ext. 17
1.785.537.4545 (fax)
 
610 Humboldt
Manhattan, KS 66502
 
http://www.boomer.com/about/team/andrew-hanenkamp.html
andrew.hanenkamp at boomer.com

-----Original Message-----
From: jifty-devel-bounces at lists.jifty.org
[mailto:jifty-devel-bounces at lists.jifty.org] On Behalf Of Edmund von der
Burg
Sent: Thursday, March 15, 2007 6:47 PM
To: Nifty apps in a Jiffy
Subject: Re: [jifty-devel] JDBI transactions

On 15/03/07, Andrew Sterling Hanenkamp <andrew.hanenkamp at boomer.com>
wrote:
> However, I'll still look into implementing it both in Perl and in SQL 
> so that we can rely on our transactions to some extent even if our DB 
> does not support save points (e.g., SQLite) or even if a DB doesn't 
> support transactions at all (e.g., DBD::CSV).

I'd argue that if the storage backend does not support the feature then
it should not be available with that storage backend. Properly
implementing something like transactions in Perl with DBD::CSV would not
be possible without access to the low level code.

If a user needs those features they should use a backend that supports
them.

I imagine that the vast majority of users will use SQLite, mysql or
postgres, all of which have native transaction support. Nested
transactions and savepoints are usually not needed in web apps which
tend to be composed of short atomic actions. Is it really worth
implementing these in Perl? It would be great to have them as buzzwords
but do we actually need them?

I want to avoid J::DBI getting feature bloat.

Cheers,
  Edmund.
_______________________________________________
jifty-devel mailing list
jifty-devel at lists.jifty.org
http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel