Login | Register
My pages Projects Community openCollabNet
Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author Frank Sweetser <fs@wpi.edu>
Full name Frank Sweetser <fs@wpi.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