204217 - require MySQL version 4.0+

Status: RESOLVED FIXED

(Bugzilla :: Installation & Upgrading, enhancement, P3)

Description

[Myk Melez [:myk] [@mykmelez]]

MySQL version 4.0+ has a number of useful features including UNIONs that we
can't use because we still allow installations to use version 3.23.  Version
3.23 is still supported by the MySQL project, but they have labeled it their
"older supported release", and it will only get critical bug fixes.  All their
efforts are now concentrated on the stable production 4.0 release and later
releases, and they recommend that all MySQL users upgrade to 4.0.

We should require 4.0 early in the next development cycle so that we can start
to take advantage of its unique features to make Bugzilla better.

Comment 1

[Bradley Baetz (:bbaetz)]

I have no problem with requring this when we need to, but unless someone is
planning to make bugzilla use transactions, or something, theres no need, and I
don't see a need to up the version requirement just because.

What features ere you thinking of?

Comment 2

[Myk Melez [:myk] [@mykmelez]]

Some that I can't remember right now, but which will come to me eventually (at
which point I'll mention them in this bug), plus bug 24957, which I think would
be best fixed with UNIONs.

Comment 3

[Matthew Tuck [:CodeMachine]]

Subselects would be brilliant (are they 4.0 or 4.x?), but can we guarantee these
features are present on all the databases we intend to support?  Sybase in
particular from what I've seen seems to have some significant holes (feels like
MySQL all over again), although I don't know about the support for these
specific features, except Oracle, which I'm sure supports them all.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

We can't develop to the lowest common denominator we'll miss critical features
that make Bugzilla much more useful.  Cross-database compatibility is not more
important than making Bugzilla as useful as possible for its users.  Regular
expression, full-text, and soundex searches are among the current, upcoming, and
potential Bugzilla features that we wouldn't get if we insisted on compatibility
with some of the major RDBMSes like Sybase and Oracle (none of which we
currently support, by the way).

This doesn't mean we can't support multiple databases, it just means we have to
code the multi-database support to do something sensible when a database doesn't
support a given Bugzilla feature.  Whatever we do, we shouldn't dumb down
Bugzilla for all databases we support; that would make Bugzilla too dumb.

Comment 5

[Matthew Tuck [:CodeMachine]]

I'm not in the slightest suggesting we work towards the lowest common
denominator - indeed I've been suggesting generic subs to abstract over
differences for some time, such as for REGEXP conditions, transactions, and so
on.  And sure, don't refuse a good optional feature if it requires database
features without universal support.

What I'm talking about is not for optional features, but for core functionality.
 For example, the proper solution to the problem for bug #127200 would have been
subselects, and I think they would help improve our querying functionality
dramatically in general.  But I'm not sure we want to write core code in a way
that prohibits databases without subselects?

I'm not necessarily against a policy that requires some advanced features, if
they can give us big wins in expressivity, such as UNIONs, INTERSECTIONs, and
especially subselects.  That is just not the tack we have taken in the past - we
have been trying to remove non-standard stuff, but in reality standardness and
support are independent, and the latter is what really matters, which is why
UNIONs are as much of an issue as, say, the non-standard field types we use (but
some of which are supported enough to be in PgSQL as well as MySQL).

Perhaps we need to write out what a database needs to support, refuse to support
databases that don't, and stick to it?  Or perhaps my definition of "core" is
too strict, and we would be willing to sacrifice some features we already have,
on some databases, by changing to a nicer implementation that is less supported?

Comment 6

[Myk Melez [:myk] [@mykmelez]]

Sorry, I misunderstood you.  I agree, we need to look at advanced database
features that we use for core functionality and make decisions about them.  We
can also sacrifice "core" in some cases, but the porters should be doing that
work.  It shouldn't be every Bugzilla developer's responsibility to fix problems
with every database that someone has got working (whether we add additional
"supported" databases is another question; I wouldn't mind having a first-class
PostgreSQL implementation).

At the moment we only have one supported database, however, so I think the
question is easier: what features in MySQL can we use to make our product
better?  Particularly with what you call standard DB features like unions,
intersections, and subselects, I think the answer is that we can and should use
all of them.

Comment 7

[Max Kanat-Alexander]

I think an important thing to consider for this bug is that Red Hat has said
that they will not ship MySQL 4.0, for licensing reasons. This means that every
customer using Red Hat 9, Fedora Core 1, and RHEL 2.1/3 will likely already have
applications built on MySQL 3, and for some users of Bugzilla, an upgrade from
MySQL 3 to MySQL 4 might be considered dangerous, or "risky" from a corporate
standpoint. Particularly for Red Hat's Enterprise Linux customers, who paid a
lot for support and won't get it with MySQL 4.

I still think we should require MySQL 4, I just wanted to note this
consideration. :-)

Comment 8

[Gervase Markham [:gerv]]

> I think an important thing to consider for this bug is that Red Hat has said
> that they will not ship MySQL 4.0, for licensing reasons.

This was because of incompatibilities between the GPLed client libraries and a
lot of other code. I have a feeling this will change, now MySQL AB have changed
their licensing to have an "Open Source exception".

Gerv

Comment 9

[Bradley Baetz (:bbaetz)]

We could just require postgres :)

Comment 10

[Max Kanat-Alexander]

I think we should require it for 2.22. We actually have *all* the infrastructure
necessary to support cross-DB work for 2.22 already awaiting review, so it would
be nice to have it then.

Note that this is still targeted at 2.20... is that actually true?

Comment 11

[Steve Wardell]

In response to an update for comment 7, Fedora 4 and RHEL 4 will include MySQL
4.1.7+. It's already built and checked in to their rawhide in preparation for
those next versions of Fedora / RHEL in 2005.

Comment 12

[Kevin Benton]

(In reply to comment #9)
> We could just require postgres :)

We would loose a lot of users who would not want to maintain two DB's because
they're using MySQL for other things.  It seems to me that requiring MySQL 4.x
is a much easier requirement to get to because admin's can simply upgrade their
MySQL without having to go through DB conversions, and all the other headaches
involved.  Since mysql.com has RPM's for Redhat distributions, that should be a
non-issue for most.

Much like many vendors have stopped supporting Windows 98, but support Windows
98 SE, it's not like we're asking users to make a dramatic shift in how they do
things.  We're asking them to be "reasonably" current with their software so we
can take advantage of the features available in the newer releases.  We
certainly wouldn't expect the gas company to continue sending meter readers to
houses forever when they could choose to install automatic reading devices... 
There's a real cost to us in staying back at 3.x.  I'd like to see us take
advantage of the improved speed (if nothing else) of 4.x, though many of the
features listed above in the comments make great sense.  For reporting,
subselects make generating those reports a ton easier.

Comment 13

[Dave Miller [:justdave]]

Reassigning bugs that I'm not actively working on to the default component owner
in order to try to make some sanity out of my personal buglist.  This doesn't
mean the bug isn't being dealt with, just that I'm not the one doing it.  If you
are dealing with this bug, please assign it to yourself.

Comment 14

[Kevin Benton]

Unfortunately, this is a Dave decision and needs to be handled by you, Dave. :)

Comment 15

[Jacob Steenhagen]

I would go as far as to say that it should be decided upon soon. It would be
nice if we were able to say in the 2.20 release notes that MySQL 3.23.x is
depreaciated and will no longer be supported in future releases (if that's the
decision). That would give people time to plan an upgrade to MySQL independent
of the planning for the Bugzilla upgrade and in the spirit of only changing one
thing at a time.

Comment 16

[Dave Miller [:justdave]]

consider this an official blessing then.  Bug 287668 filed for release notes. 
Moving this to Installation/Upgrading so checksetup.pl can be fixed on the trunk
after we branch for 2.20.

Comment 17

[Robert Kaiser]

(In reply to comment #3)
> Subselects would be brilliant (are they 4.0 or 4.x?)

Subselects are 4.1, just as a note. And 4.1 is still not included in many
distros (including e.g. current SuSE 9.2), so you'll have to be careful with
requiring that.

Comment 18

[Max Kanat-Alexander]

OK, I think that's pretty much my issue, then.

Comment 19

[Max Kanat-Alexander]

Attachment: Require 4.0.2

As I recall, 4.0.2 is the minimum version of 4 that we require.

Comment 20

[Colin Ogilvie [:cso]]

Can you also change docs/xml/Bugzilla-Guide.xml as well please, when you're
fixing this.

xml/Bugzilla-Guide.xml: <!ENTITY min-mysql-ver "3.23.41">

Comment 21

[Max Kanat-Alexander]

Attachment: v2

OK, I've fixed the docs, too.

Comment 22

[Frédéric Buclin]

(22:58:21) LpSolit: mkanat: just by curiosity, does Pg accept this SQL request?
 INSERT INTO bug_group_map (bug_id) SELECT bugs.bug_id FROM bugs LEFT JOIN
bug_group_map ON bugs.bug_id = bug_group_map.bug_id WHERE bug_group_map.bug_id
IS NULL;
(22:58:52) LpSolit: mkanat: MySQL 4.0.14 is required
(22:59:08) mkanat: LpSolit: Yes, most certainly.

This kind of SQL statement is very useful when there are missing values in a
table. we avoid an additional SQL statement. This would be useful for both
checksetup.pl and sanitycheck.cgi. So requesting >= 4.0.14.

Comment 23

[Max Kanat-Alexander]

Attachment: Require 4.0.14

OK. After reading through all the changelogs from 4.0.0 to 4.0.14, I agree with
LpSolit. We can and should require 4.0.14. SuSE 9 ships with 4.0.15, so that's
sort of my baseline for saying that this is an OK requirement. Also, 4.0.14 is
from 2003, so we're not asking for anything too recent.

Comment 24

[Joel Peshkin]

Comment on attachment 188862 [details] [diff] [review]
Require 4.0.14

r=joel
(even works with mysql5)

Comment 25

[Max Kanat-Alexander]

Hooray! :-)

Checking in checksetup.pl;
/cvsroot/mozilla/webtools/bugzilla/checksetup.pl,v  <--  checksetup.pl
new revision: 1.416; previous revision: 1.415
done
Checking in Bugzilla/DB/Mysql.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/DB/Mysql.pm,v  <--  Mysql.pm
new revision: 1.25; previous revision: 1.24
done
Checking in docs/xml/Bugzilla-Guide.xml;
/cvsroot/mozilla/webtools/bugzilla/docs/xml/Bugzilla-Guide.xml,v  <-- 
Bugzilla-Guide.xml
new revision: 1.53; previous revision: 1.52
done