Login | Register
My pages Projects Community openCollabNet

Discussions > dev > MySQL and other sql patch

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

current
Discussion topic

Hide all messages in topic

All messages in topic

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-23 13:51:48 PDT
Message On Wed, Jul 23, 2003 at 04:49:08PM -0400, Hunter Matthews wrote:
> Frank,
> We've not applied your patch - we just couldn't. The backend was (and
> really still is) changing too quickly to have to update two.

So I've noticed =)

> However, I *think* most of the noise (the capitalization part) are
> checked in now.
>
> It also appears that the "on(something)" syntax that caused so many
> duplicate SQL strings is not required. Let me test that tonight, and if
> postgres is happy with it we should be able to share all the SQL strings
> between databases.

Excellent. Once it settles down, I'll be happy to start working on pulling
more commong code into the currentDB module.

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

Re: MySQL and other sql patch

Reply

Author hunterm
Full name Hunter Matthews
Date 2003-07-23 13:49:08 PDT
Message Frank,
   We've not applied your patch - we just couldn't. The backend was (and
really still is) changing too quickly to have to update two.

However, I *think* most of the noise (the capitalization part) are
checked in now.

It also appears that the "on(something)" syntax that caused so many
duplicate SQL strings is not required. Let me test that tonight, and if
postgres is happy with it we should be able to share all the SQL strings
between databases.



On Tue, 2003-07-08 at 13:28, Frank Sweetser wrote:
> On Tue, Jul 08, 2003 at 12:26:44PM -0400, Hunter Matthews wrote:
> > One thing I'm curious about (I'm new to SQL programming, unfortunately)
> > is - is it at all possible to share the schema definitions between
> > databases? From what I've seen, the answer is "not at all".
>
> In theory - I believe so, yes. In reality, only with the most trivial table
> definitions. CREATE statements seem to be one of the areas in which each
> database engine varies the most, probably because they get used so infrequently
> and hardly ever in day to day operations.
--
Hunter Matthews Unix / Network Administrator
Office: BioScience 145/244 Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.


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

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 10:28:41 PDT
Message On Tue, Jul 08, 2003 at 12:26:44PM -0400, Hunter Matthews wrote:
> One thing I'm curious about (I'm new to SQL programming, unfortunately)
> is - is it at all possible to share the schema definitions between
> databases? From what I've seen, the answer is "not at all".

In theory - I believe so, yes. In reality, only with the most trivial table
definitions. CREATE statements seem to be one of the areas in which each
database engine varies the most, probably because they get used so infrequently
and hardly ever in day to day operations.

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

Re: MySQL and other sql patch

Reply

Author hunterm
Full name Hunter Matthews
Date 2003-07-08 09:26:44 PDT
Message On Tue, 2003-07-08 at 09:12, Frank Sweetser wrote:

[Another email, I hit send to early]

By all means, if there's code that can be shared between databases, push
it up to CurrentDB. Thats where quite a bit of the code in the postgres
backend belongs, really.

One thing I'm curious about (I'm new to SQL programming, unfortunately)
is - is it at all possible to share the schema definitions between
databases? From what I've seen, the answer is "not at all".


--
Hunter Matthews Unix / Network Administrator
Office: BioScience 145/244 Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.


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

Re: MySQL and other sql patch

Reply

Author Hunter Matthews <thm at duke dot edu>
Full name Hunter Matthews <thm at duke dot edu>
Date 2003-07-08 09:23:08 PDT
Message On Tue, 2003-07-08 at 08:50, Frank Sweetser wrote:
> > On Mon, 07 Jul 2003, Frank Sweetser wrote:
> >
> > > I've attached a patch which adds a new db_type, 'sql'. I started out by
> > > just copying db/postgres/ and then hacked it up to work with either mysql
> > > or postgresql based on a new config var, 'db_driver'. It should still work
> > > just as before with postgresql, though I've only really tested it with
> > > mysql so far.
> > 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.

I agree with John.

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

Wonderful. Do it.

--
Hunter Matthews Unix / Network Administrator
Office: BioScience 145/244 Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.


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

Re: MySQL and other sql patch

Reply

Author jwbernin
Full name John Berninger
Date 2003-07-08 06:46:05 PDT
Message On Tue, 08 Jul 2003, Frank Sweetser wrote:
> 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?
        When an exception is thrown, the code never reaches the commit.
When the thread dies, any uncommitted transactions are automatically
rolled back. The philosophy is "What isn't explicitly correct is
assumed to be incorrect and should be rolled back."


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

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

Re: MySQL and other sql patch

Reply

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

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 05:50:35 PDT
Message On Mon, Jul 07, 2003 at 08:32:38PM -0400, John Berninger wrote:
> OK, here's my $0.02
>
> On Mon, 07 Jul 2003, Frank Sweetser wrote:
>
> > I've attached a patch which adds a new db_type, 'sql'. I started out by
> > just copying db/postgres/ and then hacked it up to work with either mysql
> > or postgresql based on a new config var, 'db_driver'. It should still work
> > just as before with postgresql, though I've only really tested it with
> > mysql so far.
> 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.

...

> > Whadya think?
> 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.

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

Re: MySQL and other sql patch

Reply

Author jwbernin
Full name John Berninger
Date 2003-07-07 17:32:38 PDT
Message OK, here's my $0.02

On Mon, 07 Jul 2003, Frank Sweetser wrote:

> I've attached a patch which adds a new db_type, 'sql'. I started out by just
> copying db/postgres/ and then hacked it up to work with either mysql or
> postgresql based on a new config var, 'db_driver'. It should still work just
> as before with postgresql, though I've only really tested it with mysql so far.
        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.

> In addition, it should make it pretty easy to add other sql drivers without too
> much copying of code.
        We've already got this capability - if there's similar code, it
should go into the "backend" base class.

> I only made minimal changes to the actual sql queries. The only bits I did
> really have to change were capitilization of table names (mysql is case
> sensetive, while it appears that postgresql is not) and a slightly differing
> distinct syntax.
        This is all good - mionimal changes are a good thing. :)

> Whadya think?
        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...

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

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-07 16:03:24 PDT
Message I've attached a patch which adds a new db_type, 'sql'. I started out by just
copying db/postgres/ and then hacked it up to work with either mysql or
postgresql based on a new config var, 'db_driver'. It should still work just
as before with postgresql, though I've only really tested it with mysql so far.
In addition, it should make it pretty easy to add other sql drivers without too
much copying of code.

I only made minimal changes to the actual sql queries. The only bits I did
really have to change were capitilization of table names (mysql is case
sensetive, while it appears that postgresql is not) and a slightly differing
distinct syntax.

Whadya think?

--
Frank Sweetser fs at wpi.edu
WPI Network Engineer
Attachments
Messages per page: