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