Closed Bug 204217 Opened 20 years ago Closed 18 years ago
SQL version 4 .0+
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.
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?
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.
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.
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.
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?
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.
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. :-)
> 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
We could just require postgres :)
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?
Severity: normal → enhancement
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.
(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.
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.
Assignee: justdave → general
QA Contact: mattyt-bugzilla → default-qa
Unfortunately, this is a Dave decision and needs to be handled by you, Dave. :)
Assignee: general → justdave
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.
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.
Assignee: justdave → installation
Component: Bugzilla-General → Installation & Upgrading
(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.
OK, I think that's pretty much my issue, then.
Assignee: installation → mkanat
As I recall, 4.0.2 is the minimum version of 4 that we require.
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">
OK, I've fixed the docs, too.
(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.
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.
Attachment #188862 - Flags: review?(LpSolit) → review?(bugreport)
Comment on attachment 188862 [details] [diff] [review] Require 4.0.14 r=joel (even works with mysql5)
Attachment #188862 - Flags: review?(bugreport) → review+
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
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.