[Genquire-dev] to Commit or not to Commit

[David Block]

Your flat-file context should do something different with commit.  Of 
course.  It doesn't have a DBMS behind it.  So your Context.pm should do 
nothing if asked to commit.

A transactional database is a wonderful thing, yes, but removing the 
autocommit from that code won't automatically make Genquire take 
advantage of transactions properly.  Transaction commits right now are 
placed where they are so that each database change is an atomic 
operation, including updating the Discard table and creating whatever 
associated Container rows, etc. are necessary.

The functionality you are thinking of, which Ewan talked to you about in 
Hinxton, would add an extra step to the editing process.  Now, that is 
not necessarily a bad thing, if that extra step is a "yes, I'm happy 
with how this looks now - let's publish it".  But that's not how 
Genquire works now - now it's a very live connection, so if you don't 
like something, change it back!  What we need instead is Edit->Undo.

So before you mess with GQ::Server::DB::Context, think of all the other 
things that have to change.  Where are the logical transactional 
points?  How do you express that in the gui?  How do you ensure that a 
whole days' worth of edits isn't committed right at the end?  What about 
the lock mechanism?

Nothing rash, please.  Leave things in GQ::Server::DB the way they are, 
and mess around all you like in GQ::Server::GB.  Publishing via 
GQ::Server::DB is something I haven't signed off on, yet.

Dave
Not quite as grumpy as I sound


On Thursday, December 20, 2001, at 09:10  AM, Mark Wilkinson wrote:

> David Block wrote:
>
>>> Would anyone object to me pulling the "auto" out of "autocommit"?
>> What the heck are you talking about?
>
> well, in the current Genquire adaptor there is no user-control over the
> decision to commit.  The $dbh->commit call is in an eval statement, and 
> if
> it fails, Genquire assumes that the database can not handle 
> transactions and
> sets "autocommit" to true.  If the call succeeds, then it sets 
> "autocommit"
> to false, and allows the statement to be executed at each _update_db
> call...  but it makes no difference in the end since the $dbh->commit 
> call
> is hard-coded, so whether you want it or not the changes are commited
> automatically under both circumstances.... which defeats the purpose of
> having transactions in the first place, yeah? (or am I missing 
> something?)
>
>> You mean database updating not being live?  Which Commit are you
>> worrying about here?
>
> yes.
>
>
>> Yes, that is a good idea.  Flat files are much more of a 
>> 'edit->publish'
>> paradigm than a database which allows edits in-place.
>
> but... a database that supported transactions would allow you to do an
> editing session and then decide whether or not to keep it, right?
>
>
>> I'm pretty sure it does - SeqIO->write_seq?  EMBL->GenBank->EMBL is one
>> of the tests that is talked about on bioperl-l.
>
> I had thought so, but I have never actually used it, so...
>
>
>> Yes.  Good thing we have this list, eh?
>
> what do you object to?
>
> M
>
>
> --
> --------------------------------
> "Speed is subsittute fo accurancy."
> ________________________________
>
> Dr. Mark Wilkinson
> Bioinformatics Group
> National Research Council of Canada
> Plant Biotechnology Institute
> 110 Gymnasium Place
> Saskatoon, SK
> Canada
>
>
>
>
> _______________________________________________
> Genquire-dev maillist  -  Genquire-dev@bioinformatics.org
> http://bioinformatics.org/mailman/listinfo/genquire-dev
>
>
David Block          (858)812-1513
Bioinformatics        http://www.gnf.org
dblock@gnf.org        Just ridin' the Coaster...