Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: MySQL and other sql patch

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

current
Discussion topic

Back to topic list

Re: MySQL and other sql patch

Reply

Author Frank Sweetser <fs at wpi dot edu>
Full name Frank Sweetser <fs at wpi dot edu>
Date 2003-07-08 06:12:06 PDT
Message On Tue, Jul 08, 2003 at 09:04:49AM -0400, John Berninger wrote:
> > Fair enough. With the backend api, though, this would require a lot of
> > code duplication that's not db dependant. Would you object to moving code
> > out from the backend, and into the currentDB class? What I'm picturing in
> > this case is reduce the backend more or less to to set and get functions,
> > and leave all of the various rpm and filesystem logic up to the currentDB
> > class.
> If the code move makes sense and reduces duplication of
> identical code, I'm all for it. Fly it by the list, by all means. I
> just don't want to end up subclassing 5 times to get to the "real stuff"
> - I'm already a bit leary of how far we've subclassed bu I can't think
> of a way to flatten it more.

Agreed - bajillions of subclassing just makes debugging that much more...
interesting. My thought is that it wouldn't make sense to create any new
classes, just to move some commong code out of the child classes up into the
currentDB class.

> The only hard requirement I've got is that the backend be able
> to handle transactions. If an RPM insertion fails partway through, it
> *will* be rolled back - the database absolutely cannot be left with
> partial information. That's actually the reason I started with
> PostgreSQL - MySQL didn't have transaction support, and as far as I
> know, still doesn't.

MySQL with InnoDB tables support full transactions. It ships with standard
MySQL under the same licensing, so I don't think it would be too unreasonable
to require it to use MySQL with current.

> If you can make it work with a "fake" transaction support, go
> for it - I just couldn't see how to do so.

Taking a quick glance though the postgresql code, I only see explicit commit
statements, no explicit rollback statements. How do the rollbacks get
triggered on failure?

--
Frank Sweetser fs at wpi.edu
WPI Network Engineer

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
For additional commands, e-mail: dev-help at current dot tigris dot org

« Previous message in topic | 5 of 11 | Next message in topic »

Messages

Show all messages in topic

MySQL and other sql patch Frank Sweetser <fs at wpi dot edu> Frank Sweetser <fs at wpi dot edu> 2003-07-07 16:03:24 PDT
     Re: MySQL and other sql patch jwbernin John Berninger 2003-07-07 17:32:38 PDT
         Re: MySQL and other sql patch Frank Sweetser <fs at wpi dot edu> Frank Sweetser <fs at wpi dot edu> 2003-07-08 05:50:35 PDT
             Re: MySQL and other sql patch jwbernin John Berninger 2003-07-08 06:04:49 PDT
                 Re: MySQL and other sql patch Frank Sweetser <fs at wpi dot edu> Frank Sweetser <fs at wpi dot edu> 2003-07-08 06:12:06 PDT
                     Re: MySQL and other sql patch jwbernin John Berninger 2003-07-08 06:46:05 PDT
                     Re: MySQL and other sql patch hunterm Hunter Matthews 2003-07-08 09:26:44 PDT
                         Re: MySQL and other sql patch Frank Sweetser <fs at wpi dot edu> Frank Sweetser <fs at wpi dot edu> 2003-07-08 10:28:41 PDT
                             Re: MySQL and other sql patch hunterm Hunter Matthews 2003-07-23 13:49:08 PDT
                                 Re: MySQL and other sql patch Frank Sweetser <fs at WPI dot EDU> Frank Sweetser <fs at WPI dot EDU> 2003-07-23 13:51:48 PDT
             Re: MySQL and other sql patch Hunter Matthews <thm at duke dot edu> Hunter Matthews <thm at duke dot edu> 2003-07-08 09:23:08 PDT
Messages per page: