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 jwbernin
Full name John Berninger
Date 2003-07-08 06:04:49 PDT
Message On Tue, 08 Jul 2003, Frank Sweetser wrote:

> > Uhhh.... no. I put the db_type variable in to distinguish
> > between backends, not add another layer. I've got no problems with the
> > concept of a MySQL backend, but it will be put in with a db_type of
> > 'mysql' or something similar, not with a completely new config variable.
> 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.

> > Well, I'm forced to temper my thoughts due to the fact that
> > there is a *major* problem with the DB schema as it exists at this
> > time... the changes I'm going to have to make to fix this bug are going
> > to be pretty extensive, and will probably end up breaking your code all
> > to heck and back. I'll try to get something committed this week, but
> > I'm way busier than I expected to be at this point, so no promises...
> Okay - that shouldn't make much difference to the stuff I'm thinking of doing
> as long as you don't depend upon any postgresql features that can't be faked
> in mysql. I'll hold off on working on it until you get the schema stuff
> straightened out, though.
        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.

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

John Berninger

GPG Key ID: A8C1D45C
        Fingerprint: B1BB 90CB 5314 3113 CF22 66AE 822D 42A8 A8C1 D45C

Sit vis nobiscum.

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