Jump to content

Talk:MySQL/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2

The "old bugs" edit warring

I've left a comment with the (new) user who is reinserting this material to explain why it isn't suitable. For now, let's calm down and discuss it instead of carrying on with an edit war which will result in the page getting protected. Chris Cunningham (not at work) - talk 12:48, 24 July 2008 (UTC)

Apparently an unhappy former user of MySQL: "The reason why I am after this is that I have wasted around 1 and a half year on MySQL without ever being able to come up with a reliable solution".[1]. So, looking at what he claims with this pair of edits:

  1. "Critical bugs sometimes do not get fixed for long periods of time."
    No reputable source for this claim is given, it seems to be just the unhappy former user claiming it. Two references are given:
    1. a PostgreSQL core team member claiming that much of the code removed in creating an experimental version called Drizzle is extremely buggy. PostgreSQL is a competing database that the unhappy user has switched to.
    2. one of MySQL's founders asking for help testing 5.1 so that all possible bugs are found before release
    With no citations for the comment it should be removed, unless a reputable source making the claim can be found.
  2. "An example is a bug with status critical existing since 2003" and citing bug 989.
    1. The Status is currently "Patch pending", not "critical".
    2. The Severity is "S1 (Critical)" apparently because it's a piece of missing functionality. The bug is that if one person started adding data to a table then another person threw the table away, an entry to the backup and replication log for the adding work would be made after the throw away entry, so if a backup was being restored there would be a warning message even though the data would be thrown away anyway, because the table where it was being added no longer exists. That hardly seems critical, which probably explains why MySQL hasn't fixed it yet.
    3. MySQL has a formal bugs classification process and that has graded this bug as:
      1. D2 (Serious) serious defect, but not D1, a critical defect.
      2. R2 (Low) risk of introducing new bugs by fixing this one.
      3. E3 (Medium) effort to fix it.
    So this single bug report also seems not to support the claim that critical bugs have remained unfixed for years.

I searched the MySQL bugs databases for all bugs that the formal process classed as D1 (critical). There are fifteen of them at the time I write this. Just three are more than seven months old:

  1. The first is bug 21476, if you deliberately set the stack size to two thirds of it's normal and recommended size you can make the server crash instead of giving an error message.
  2. Second is bug 28756, a crash in an old version of Mac OS used on one of MySQL's internal test machines and the suggested fix is upgrading the test machine operating system to a more recent version because it's not really a MySQL bug.
  3. Third is bug 31435, where the last comment says that it's fixed and should be closed.

So MySQL's bug system and formal bug classification system really says that the only critical bug in the server that's more than seven months old only happens if someone seriously misconfigures the server. That contradicts the claim that critical bugs are left unfixed for long periods of time. A similar criticism was first (?) added by the same user back in April 2008 and removed by Chris Cunningham (not at work) in May 2008. Given the clear motive of the person adding this, the lack of any reputable source for the statement and the lack of real support for it there seems little merit for its inclusion.

Since Chris Cunningham (not at work) has already engaged in several edits disagreeing about including this and I've done this analysis, would someone else review and act appropriately to continue the proces of establishing consensus that this is just POV-pushing by an unhappy user? Jamesday (talk) 06:02, 8 August 2008 (UTC)


There is a major stackpile of "relatively important" bugs in MySQL that haven't been fixed for at least 5 years, this is nothing new, attempting to ignore it on the wikipedia page is yet more censorship ... and quit talking about WP and OR when you accept marketing information as an external source -- this is so full of bias it makes this article worthless...Yourbane (talk) 08:59, 29 August 2011 (UTC)


Critical bugs

Thanks for that Jamesday. I really believe there is a lack of critical information about MySQL. The bug I came up with is just one example of a long list of critical bugs. For example try reading halfway down the page at http://www.oreillynet.com/pub/a/databases/2006/08/10/mysql-federated-tables.html?page=4 this issue is an ugly surprise when one tries to use the Federated engine for ad-hoc queries where it is impossible/impractical to create indexes for everything. Not sending the "where" clauses to the remote server is an amazing missing functionality (I cannot imagine any reason for this apart from extreme time pressure on the developer). In our case, we had a complete application, which to our surprise performed dreadfully when there were more than a few thousand rows in a table (as all rows where sent across the internet).

Do you understand why the bug I refer to in the article does not show up on the search you provided: http://bugs.mysql.com/search.php?cmd=display&bug_type=Server&status=Active&os=0&bug_age=0&priority=all&limit=30&defect_class=-1&workaround_viability=all&impact=all&fix_risk=all&fix_effort=all&reorder_by=date

It should surely show up there. Some time ago when I ran the same query, lots of older bugs showed up, but now I cannot see the really old ones.

I am not trying to undertake a vendetta on MySQL, I just believe that the Wiki article should have some criticism on MySQL in order to be more neutral. My problem was that I didn't spend enough time documenting my claims and finding references (I assumed others would contribute to the criticism part as well) before writing in into the article. So obviously I stepped on someones toes.--Hulagutten (talk) 18:37, 25 August 2008 (UTC)

Your search is for active bugs, those that have pending work. A bug is no longer active once it has been fixed. So the bugs vanishing is a good thing.
The Federated storage engine isn't turned on by default any more in MySQL 6.0 so it seems that MySQL agrees that it needs more work to be a really high performance engine. You might try a second copy of MySQL on the same server that replicates from the remote server. Then you can load from that copy without having to use the internet.
The text "An example is a bug with status critical existing since 2003" isn't accurate. Its Severity (not its status) was originally rated critical because if it happens it can be annoying (you might have to edit the text version of a binary log to use it as part of restoring a backup) but it's Status is "in progress" and it seems to be something that'll be fixed in 6.0. To have that problem in the first place you have to drop a table while some other transaction is actively using it. That's a crazy thing to be doing; you'd want to drop when the table isn't in use. Nice to fix it but I have difficulty thinking that a problem that requires you to be crazy to experience it is a critical one.
I have to disagree here, although it's a crazy thing to be doing, sometimes people drop tables, and sometimes it's possible that there'll be an open (even hanging) transaction. A transactional engine CANNOT allow that, thus that problem was a major fail in terms of ACID compliance. strictly unacceptable from a product that tries to be on par with real dbms's.
I suppose it's worth updating the status of the three bugs that MySQL thought were critical when I did that search back in August. Bug 21476 was fixed in version 6.10 for the only platform that was still affected, HP-UX. Bug 28756 is not fixed; looks as though it's not annoying MySQL's developers, who are the only people who see it, much. According to the comments on the patch review, bug 31435 was really fixed back in November 2007 and all that's left is to do is remove a redundant error message. Not really a lot there to support a claim that bugs that MySQL really thinks are critical are left for years.
There are other bugs in MySQL that have been there for 5 years and aren't fixed yet ... A whole lot of them - anyone who ever posted a bug on MySQL has probably seen this.. lots and lots of bugs sitting there not moving.
For a more balanced view of MySQL reliability you might take a look at You don't build server software with an MTBF from software crashes measured in centuries (yes, that is what I get now) by being lucky, written by the guy who looks after the MySQL servers that are used in Google's AdWords system. That might be a nice quote to add some balance to the bugs paragraph. Jamesday (talk) 07:21, 5 March 2009 (UTC)
That guy works in designing reliable systems built from unreliable blocks, usually based on inexpensive hardware, mass replication and auto failover. So in his case, the fact that MySQL could be a pile of shit does not matter.
Articles do not just add "criticism" in order to be "neutral". If criticism has been featured in reliable, secondary sources then it can be added, inoorporated appropriately into the rest of the prose. Otherwise, it should not be. Bug lists are original research, and are unsuitable. Chris Cunningham (not at work) - talk 10:33, 5 March 2009 (UTC)
If you are up for the task of making a comment next to all features that are affected by the 55 unfixed critical bugs stated by the creator of MySQL (Michael "Monty" Widenus) (see http://planet.mysql.com/entry/?id=16232), then you are welcome to remove the critisism section. In addition, one of the initial sentences of the article should state that MySQL has many unfixed critical bugs, which might crash the database from time to time, leading to dataloss and/or downtime.--hulagutten (talk) 21:23, 9 June 2009 (UTC)
(copied from user talk:Hulagutten#Removal of cleanup tags:
As has been repeatedly pointed out to you, that MySQL has open critical bugs (incidentally, "critical" is just a triage level; Firefox has open critical-level bugs, as do almost all free software projects) does not in itself require us to do anything to warn readers, nor is it in itself a point of criticism. The only time we can record criticism is where a reliable secondary source is doing the criticising. You have repeatedly been asked to provide such sources and the only thing you've come up with is primary sources which explain the bugs themselves (i.e. bug tracker items) or rants on forums and blogs. This has predictably failed to sway consensus that segregating negative points from the rest of the article is a bad idea. Should you have no argument based on an understanding of our policies on original research and synthesis of argument to counter the consensus that a segregated section for negative material is a bad idea, the cleanup tag shall be re-added. Chris Cunningham (not at work) - talk 23:00, 9 June 2009 (UTC)
Please read http://planet.mysql.com/entry/?id=16232. The author is Michael "Monty" Widenus, the creator of MySQL. Please tell me that he has no authority to criticize MySQL and that it is not a secondary source. —Preceding unsigned comment added by Hulagutten (talk • contribs) 20:32, 10 June 2009 (UTC)
That's a blog post expressing concern that the release process for 5.1 was flawed. That, not the bugs therein, is the overarching theme of the post. As the author is directly associated with MySQL, it is a primary source. Using that blog post to criticise MySQL for having "critical bugs" is at best a misreading and at worst deliberate twisting of words. I'm inclined to think that the latter is more likely given your previous statements. Chris Cunningham (not at work) - talk 09:13, 11 June 2009 (UTC)
The article states that the product is flawed due to a flawed release process. These things are strongly related. If you release too early the product will have critical errors. Michael Widenus is an insider who critizises his own organization and his own product. You cannot find a more reliable source than that. If this is not good enough, please stop harassing those that try to improve this article by referencing credible sources and go get your damn secondary sources yourself. —Preceding unsigned comment added by Hulagutten (talk • contribs) 12:53, 11 June 2009 (UTC)
Again, it is the release process for a particular cycle which is being criticised in that blog post and not the product itself. I'm restoring the tag, as it is not the lack of secondary sources which is being pointed out but that the section is being used as a deliberate effort to draw negative attention on the subject by an editor who has repeatedly stated that his aim on this article is to highlight the problems he had with it personally. Chris Cunningham (not at work) - talk 13:48, 19 June 2009 (UTC)
On a completely unrelated note, Wikipedia uses MySQL, this article is full of shit and propaganda (MySQL supports triggers because Orcl said so = good info / MySQL bad because dev said so = bad info ... etc. etc. etc.) and it seems there are people here full-time to protect it from any possible criticism, friggin shame ... how many more noobdevs will have to wait several years (while using mysql) before discovering what a real dbms is ... and it's all your fault, ebil moderators of doom -- Yourbane (talk) 08:56, 29 August 2011 (UTC)
Am I am ebil moderator of doom? Anyway, your statement "...before discovering what a real dbms is" is quite telling - you clearly have an axe to grind. What is a real dbms? Why don't you get off your soap box and reveal your real agenda on Wikipedia? --Simple Bob a.k.a. The Spaminator (Talk) 09:14, 29 August 2011 (UTC)

Can Oracle Kill MySQL?

Everyone I know who is watching the EU vs. Oracle battle over the future of MySQL wants to know the answer to this question: Can Oracle Kill MySQL? This is the most relevant question the Wikipedia article can address.

Oracle's stated objectives mean nothing. We want to know if the terms of the licensing enable fully functional forks of the MySQL code to evolve, or if Oracle controls enough of the components of MySQL that it could effectively shut it down if it wanted to do so.

When I google news stories, I get conflicting reports:

  • The Register paraphrases Florian Mueller as saying Oracle would hold the brand and the databases assets, and it would take somebody else years before any fork could reach the same kind of technical maturity and level of acceptance as MySQL.
  • CNET Business Tech, on the other hand, contends that Amazon's RDS and Drizzle are viable MySQL forks that could compete with Oracle.

The MySQL article here on Wikipedia talks about Oracle having bought up storage engines used by MySQL since 2005. It also talks about MySQL developing Falcon, its own storage engine, for future releases. Is this key? If Oracle kills MySQL's storage engines, would it put MySQL years behind?

What is the EU's primary concern?

  • Oracle's physical ability to control the storage devices?
  • Oracle's ability to effectively shut down future forks via licensing, or
  • Oracle's ability to use the courts as a club against anyone trying to grow a MySQL fork to something that could compete with Oracle's larger operations?

Can anyone answer these questions or provide insight toward the goal of finding answers?

Given that the EU allows an Oracle + MySQL merger to operate within its jurisdiction, is there any way possible for Oracle to effectively kill or significantly hamper future MySQL development?

My query is for the purpose of proposing a direction for future development of unfettered projects like Wikipedia built on unfettered database technology like MySQL. You have my gratitude for any insight you can provide. --MyPerson (talk) 15:15, 14 November 2009 (UTC)




IMO this discusssion lacks all the neutrality that is so well looked after with all the posts that critize MySQL. One should keep in mind that Oracle is actively developing/marketing all the other database products they have bought in, so the idea that Oracle will "kill" Oracle is at least biased. More so, at least _some_ consideration could be given to the fact that Oracle has a lot more experience with databases, both in terms of performance and stability than MySQL has, and this could mean that MySQL could benefit a lot. I know some people will disagree, ask for sources and so on, honestly I think they should come up with some by themselves. List some large databases that actually run on MySQL (>64cores, >512GB Ram). It's just inpolite that all "good" features of MySQL are published without much questioning, like i.e. reviewing the opinions of people that were unhappy with MySQL or prove a lot. —Preceding unsigned comment added by 82.135.62.109 (talk) 23:19, 21 January 2010 (UTC)



To that end, I have added the fact that Oracle's buying Sleepycat had very little impact on MySQL, as it was already deprecated in 5.0 and removed in 5.1 (in the article I wrote that it was "deprecated" in 5.1 because that's how MySQL states it).

It's unclear to me why Oracle buying Innobase OY is relevant -- MySQL never owned Innobase, so why is this in the Corporate Backing section of the MySQL article? It seems like someone wrote this section trying to show how OMG EVIL Oracle is, buying things up left and right. They didn't even bother to reference the Sun acquisition (I added a link for that)....

I think that the Oracle acquisition of Sleepycat and Innobase should be deleted, or at least moved to a separate section on 3rd-party owned storage engines, since both BDB and InnoDB always have been owned by entities other than MySQL.

Awfief (talk) 05:05, 18 February 2010 (UTC)

Remember this is about the product MySQL and not the company. InnoDB and BDB were the only engines that supported transactions. BDB wasn't much of an issue for the reasons pointed out above, but InnoDB was extremely important in gaining corporate acceptance of MySQL. With the purchases, Oracle controlled the storage engines that would determine the future of MySQL. The purchase of Innobase was directly responsible for the development of the Falcon engine, and that development only stopped when Oracle purchased Sun and therefore MySQL, securing InnoDB as the default storage engine. Ajdonnison (talk) 10:15, 20 October 2011 (UTC)

Suggest adding a section about cloud-based MySQL implementations

There are several vendors providing MySQL implementations on cloud platforms like Amazon EC2, for example Amazon Relational Database Service. I'd like to add a section to the article discussing how this works and mentioning the notable vendors. Any objection? Gilad.maayan (talk) 10:20, 31 October 2011 (UTC)

Unilaterally Removed Changes

Hello,

I made several changes on the page precising how far MySQL was with the implementation of some features (yes it was a shock to me to discover they weren't fully implemented and it seems to me logical that should be documented on public resources such as wikipedia).

And somebody just removed them.

The fact that MySQL fails to follow the SQL standard on many occasions is clear and documented in the MySQL documentation, so why remove that comment, which only reminded people that not everything is according to standard and that there is a possibility that their problem is related to that.

The fact that MySQL's trigger implementation is still very young is clear AND documented in the MySQL documentation (about the limitations, etc.) , so again, why remove ?

If you're gong to take this approach to your article, so be it, but honestly I'd rather see the truth on a wikipedia page about open source than another religion war.

BR. Yourbane (talk) 12:54, 19 August 2011 (UTC)

I assume you are talking about edits such as this? If so, there are multiple problems with such edits. First of all, the statements must be reliably sourced, particularly when adding criticism. Second, as an encyclopedia, for obvious reasons, we don't want content saying "this is wrong because XYZ". If it is wrong, fix it so other readers don't see conflicting content. –CWenger (^ • @) 15:32, 19 August 2011 (UTC)
Thanks Wenger, I think you're perfectly correct, I will thus do this nicely, probably under another subtitle and with all required references. — Preceding unsigned comment added by Yourbane (talk • contribs) 09:12, 22 August 2011 (UTC)
I"m sorry but I reverted your additions. I consider that they were not well written, were poorly sourced, and contained too much commentary e.g. "quite normal as they're not...", or "...if someone can confirm this". This is an encyclopaedia and a place for absolute statements of fact supported by well-sourced and reliable third party references. I don't consider MySQL's own bug system to be a reliable source, those specific bugs would need to be commented on by some other source e.g. a reputable industry analyst or publication. If you want to do a hatchet-job on MySQL then Wikipedia isn't the place to do it. If you want to comment on features that it doesn't implement, or has problems implementing then that's fine as long as reliable references are used and an encyclopaedic tone is adopted. --Simple Bob a.k.a. The Spaminator (Talk) 14:22, 22 August 2011 (UTC)
While I agree this would be better, you have to admit that MySQL's own manual is quite a good source and thus the comment on the ACID limitation should not have been removed. Furthermore, the other source e.g. does not seem to have been a requirement for the features list, so why insist on having much stronger support for anything of the same level ? I will thus remove the bugs and still add back what's about ACID compliance, it's still the most important part anyway. — Preceding unsigned comment added by Yourbane (talk • contribs) 09:53, 23 August 2011 (UTC)
I believe this is better. And I would like to explain here why those changes were required, so noone tries to remove them again. MySQL InnoDB does not fire triggers on cascade actions and it does not fire triggers on API actions. Because of this, any transaction including one of those methods (i.e. a CASCADE action or an API call) will result in an inconsistent state of the database, thus breaking the 'C' compliance criterion in ACID. Furthermore, MySQL's lack of compliance to the SQL standard is really a pain for any DBA coming from (or even going to) another (more-sql-compliant) DBMS and this is definitely an important information for anyone interested in MySQL. Lastly, it is a pity that I had to withdraw my comments on the performance of MySQL as I did not have time to find other references for that, because that is, again, information devs interested in MySQL should have (instead of the usual 'MySQL is as fast / faster' propaganda - I've seriously seen awful performance when it comes to slightly advanced SQL w/ MySQL) and I'll try and get good references to add it back in here. — Preceding unsigned comment added by Yourbane (talk • contribs) 10:15, 23 August 2011 (UTC)
The references that you gave for non-compliance with ACID make no mention of ACID. You need reliable third party sources to support such an assertion and those references should, of course, specifically mention ACID. --Simple Bob a.k.a. The Spaminator (Talk) 10:22, 23 August 2011 (UTC)
I can understand that you're not a DBA, and I can even forgive that you edit without any knowledge of the topic. However, the comments I reference in those STRICTLY IMPLY that InnoDB is NOT ACID compliant.
Note
Currently, cascaded foreign key actions do not activate triggers.
THIS says that CONSISTENCY is breached WHENEVER a foreign key CASCADE does not fire a TRIGGER where it should have fired one. (because a normal update or delete would have, which a cascade action is)
Please stop removing my modifications and ask any serious DBA about the implications of the above Note. thanks.Yourbane (talk) 10:47, 23 August 2011 (UTC)
Sorry, but unless you can come up with a reference that explicitly states that MySQL is not ACID compliant then what you are doing is interpreting the references that you give - which is original research. Please don't add them again without proper references. As for your assertion that I am not a DBA - how do you know who I am or what I do? That is irrelevant anyway. --Simple Bob a.k.a. The Spaminator (Talk) 11:32, 23 August 2011 (UTC)
This is not original research, it's me translating notes in what they actually mean regarding to ACID compliance. You're not a DBA, otherwise you would have understood the translation and left the reference. I write 1+1=2 and you remove it on grounds that mathematics don't mean anything to you... it's the exact same thing except we're talking SQL. What I wrote can be verified by anyone who knows what ACID means and how a DBMS works (basic), it's neutral as well and the sources are all verified.Yourbane (talk) 11:53, 23 August 2011 (UTC)
I've checked the whole page about O.R. and this is not it. Please either ask someone knowledgeable to explain you why this is indeed 1+1=2 and quit reverting the article all the time. — Preceding unsigned comment added by Yourbane (talk • contribs) 11:57, 23 August 2011 (UTC)
Tell you what I'll even explain it to you: 'The fact that a cascaded foreign key delete for example will not fire an on delete trigger means that the database will process THAT delete differently than ANOTHER delete, which is inconsistent behaviour leading to inconsistent DATA in the scope of a TRANSACTION'. 'This means that the RULES enforced by said TRIGGERS will be IGNORED because said TRIGGER will not be fired'. 'And thus this note's meaning == InnoDB not ACID compliant as long as triggers *can* be used' — Preceding unsigned comment added by Yourbane (talk • contribs) 12:05, 23 August 2011 (UTC)

Please do not add original research to the article. What don't you understand about original research? I have left warnings on your talk page which give adequate explanations including the very clear statement "Original research also encompasses combining published sources in a way to imply something that none of them explicitly say" - which is exactly what you are doing because the MySQL (primary) references that you give do not explicity state that the database is not ACID compliant. If you don't want to listen to me then invite others to this discussion or wait for other people to comment, but please don't add the content back until further discussion has taken place or until you can provided proper references. --Simple Bob a.k.a. The Spaminator (Talk) 12:55, 23 August 2011 (UTC)

Also you state "This is not original research, it's me translating notes in what they actually mean" - that is exactly what OR is. And again you have no knowledge of my occupation or expertise so stating "You're not a DBA" is irrelevant. Wikipedia isn't a competition on who is the cleverest, it is about providing properly sourced and verifiable content. Anyone can provide content, it doesn't matter whether they are a subject matter expert or not. If you find that difficult to accept then perhaps you should consider your status. --Simple Bob a.k.a. The Spaminator (Talk) 12:58, 23 August 2011 (UTC)

Seriously, what is wrong with you ? I explained you how it was strictly clearly written in the referenced materials, didn't I ? Wikipedia is not a competition of anything but you should NOT be reviewing articles on a subject you do not understand. The references I gave you EXPLICITLY say what I explained to you right here, I provided proper references, what more do you want to validate this ?? — Preceding unsigned comment added by Yourbane (talk • contribs) 13:56, 23 August 2011 (UTC)
Firstly, they are primary sources but more importantly they do not explicitly mention ACID compliance, so their use by definition is original research. In fact Oracle's own website page and its product datasheet explicitly state that it is ACID compliant, which is in contradiction to what you are attempting to assert. --Simple Bob a.k.a. The Spaminator (Talk) 14:06, 23 August 2011 (UTC)
I have to say that I agree with Simple Bob here. He has provided two refrences that clearly state that MySQL is ACID compliant. Yourbane: Do you have any sources that clearly state that it is not ACID compliant? As for conforming to MySQL standard, I think it would be useful to find a reliable source that states whether or not MySQL conforms to the standard. The refrences provided by Yourbane (or at least the ones I looked at) did not say anything about the SQL standard. Therefore, any statement based on those refrences concerning the SQL standard would be OR. Remember, on wikipedia, it doesn't matter what is true, what matters it what is verifiable. Eomund (talk) 03:10, 24 August 2011 (UTC)
The references provided that claim ACID compliance are Oracle advertisement, I hardly see how these can be considered NPOV references... but have it your way it's not my wikipedia obviously.
The references I provided are Oracle official material and explicitly state that MySQL does not conform to the standard (there's a bit about how MySQL silently ignores REFERENCES syntax for foreign keys) and the ACID part I explained enough times already. If you people cannot see how this is explicit, I'm afraid I can't do better and I'll just let this article be full of pro-MySQL POV, again wikipedia's problem not mine. Yourbane (talk) 08:02, 24 August 2011 (UTC)
I also agree with Simple Bob. It's frustrating but sometimes even when you think Wikipedia is blatantly wrong you have to let it go because that's what the sources say (see WP:V). Even very simple things violate WP:NOR. If you want to add something, particularly if it criticism, it absolutely must be supported by reliable sources. –CWenger (^ • @) 03:54, 24 August 2011 (UTC)
Hi, I just want to bring the ACID compliance issue up again. I looked at the example on the ACID page and MySQL fails with the given example. There is a bug report logged since 14 Apr 2004 3464 and it also states in its official create table documentation that "The CHECK clause is parsed but ignored by all storage engines.". So I believe listing ACID compliance as one of its feature is simply not true. I also looked at the citation given and that just points to a glossary explaining what ACID means, not stating that MySQL is ACID compliance. So I believe listing ACID compliance is not true, and should be removed or edited from the features list. I will leave it for now in hope someone corrects it or at the end of the week I will remove the line myself. 197.170.168.5 (talk) 15:47, 17 January 2012 (UTC)
I have to reiterate what I said before. Truth does not matter to wikipedia. Verifiability does. (See WP:V) Perhaps the citation does say that MySQL is ACID compliant but these two sources say that it is. Anything you find out on your own is original research and does not belong in wikipedia. If you can find a reliable source that says it is not ACID compliant, then perhaps it should be removed. Eomund (talk) 02:01, 18 January 2012 (UTC)
Thanks for the feedback Eomund and pointing me in the right direction regarding how Wikipedia works. But at the moment the citation given and even your two sources are self published. So at least citation is needed for the claim of ACID compliance from a non biased reliable source, or am I wrong? I will once again give it a week for discussion before changing the line to citation needed. 41.134.164.122 (talk) 08:22, 19 January 2012 (UTC)
I agree that the citation that is there is not sufficient. However, as per this policy, I believe the other citations are valid. Please let me know if you disagree. Eomund (talk) 01:26, 21 January 2012 (UTC)

Too Technical

Whomever thinks that this article is too technical, can you give some examples of things that need to be improved? What part is too technical? —Preceding unsigned comment added by Rsshilli (talk • contribs) 19:10, 5 March 2008 (UTC)

I think it's too technical. I am a moderately competent computer user and I decided that I wanted to put some old family pictures on my website and allow for family members to comment so we can try to figure out what these pictures from 100 years ago are of. I make the pages for my site with Dreamweaver v.8, I have a domain name with free forwarding to a friend's server where I maintain the files. I did some quick researching about how to make a comments option, like I did when I put a BBS on my site last year for a high school reunion--which is working fine. I found a script that will do the job and I expect that my friend's server running Apache will probably already have what I need to run the script (ScriptsMill Comments v1.04). But I really don't understand what a MySQL database is and as that's one of the prerequisites for running the script on my friend's server, I turned to Google and found this entry on Wikipedia. I read, no scratch that, I browsed the entry and still had no idea what a MySQL database is or how it relates to the script I want to use. SO . . . a less technical explanation would teach me (in a very general and conceptual way) about MySQL, about what the database is, and hopefully even relate it to things like the script I'm planning to use. —Preceding unsigned comment added by 76.0.240.143 (talk) 23:34, 25 October 2008 (UTC)

This encyclopedia article gave me what I expected, an explanation of MySQL. I did not expect Wikipedia to show how to use the software. At the behest of my adult son, a computer tech, I've purchased a couple books that will help me develop databases with this software. A cursory on-line search of "learning mysql" or "using mysql" showed me what I need for a good start. I expect Wikipedia will provide an introduction to software. This article seems to do that despite the subjective text complaining about the shortcomings of this inexpensive software. I've heard of some really buggy, expensive operating systems that seem to dominate the market for commercial software. There seems little justification for using Wikipedia as a podium to voice opinions and vent frustration. //Don K. (talk) 06:02, 13 July 2009 (UTC)
I browsed the entry and still had no idea what a MySQL database is or how it relates to the script I want to use
This indeed is a problem which I see as well, also in the german version of the article. I am native German and have vastly improved the German text, which more or less has the same structure as this one here. If you want to, you can translate things from there. :-) --88.130.94.28 (talk) 22:41, 1 February 2012 (UTC)

Support and Licensing Section Problems  Done

The Support and Licensing section has been tagged as being written like an advertisement, but I'm not sure what specifically is wrong with it. I can't find any obvious bias to the section. Is it just too detailed? Or is it time for the warning to be removed? Jcubed111 (talk) 22:37, 10 December 2011 (UTC)

I guess it was a mixture of both: Compared to the length of the article it seemed to be too long and its tone did not always sound neutral. I have shortened the text and rewritten it based on the text in the German WP. As I understood your text, it also was not always correct. Where you find that my new text differs from what the old text said before, I tried to fix these issues. Feel free to correct me, if I am wrong in some point. --88.130.93.156 (talk) 00:35, 4 February 2012 (UTC)

Original pronunciation

As the company is named after the daughter My of Michael Widenius of Helsinki Finland the pronunciation is originally 'me'. —Preceding unsigned comment added by 90.5.12.208 (talk • contribs) 11:37, 18 January 2008

Interesting, if true. Sources? SaulPerdomo (talk) 02:39, 22 January 2008 (UTC)
Already dealt with in-article. Widenius is ambiguous as to whether his daughter's name has anything to do with the project's, and there's been an official pronunciation for years. Chris Cunningham (talk) 11:21, 22 January 2008 (UTC)
Couldn't be, since the pronunciation of me is [mi:], while My in Swedish and Finish is pronounced [my:] or [myʲ], which for those qnowwing German or French would be like "müh" resp. "mue". My is just unpronouncable in English. Said: Rursus ☻ 10:51, 6 February 2008 (UTC)
I was in team of MySQL in 1997-2003 and can clarify a bit. Monty's daughter name is "My" and like already told it is pronounced "mü" for many European languages. This is officially told as origin of MySQL name. Meanwhile it is also known that Monty and David used my_ prefix in source code internally longer before My was born. MySQL was just logical to have. About SQL there was made decision in early days to pronounce it in Finnish way "mai ess kuu ell", not English way. So while English speaking crowd of course use their way, original authors of MySQL say "Mai ess kuu ell" like it is Finnish, Estonian, German and some other European languages.

Tõnu Samuel (talk) 03:03, 7 February 2012 (UTC)

Creators/Developers

This article does not even mention who created MySQL, or who the main developers have been. —Centrx→talk • 18:07, 16 December 2008 (UTC)

Fair enough. If I had created it, I would be ashamed. 81.208.7.130 (talk)

MySQL's SHOW AUTHORS lists 78 persons for now. But any kind of such list is not fair because there are many people who did something for MySQL for free and not mentioned. It is sort of risk to get mass of requests to be listed because so many people have submitted some patch into it. Tõnu Samuel (talk) 03:09, 7 February 2012 (UTC)

Conflict with NuSphere

I don't see where this copyright infringement should be relevant in this article, they happen all the time. This is even more the case as all info which is given is that the judge sees the GPL as being enforceable and binding, so if this should be encyclopaedically relevant at all - which I doubt - then it should go into the article about the GPL, not here. --88.130.80.109 (talk) 09:45, 8 February 2012 (UTC)

I see this event as rude attack and attempt to takeover of MySQL. This is one and only of such events in MySQL history I know about. If Nusphere would succeed......(fill the gap) Tõnu Samuel (talk) 04:41, 10 February 2012 (UTC)

NuSphere won't succeed as the case has been settled. And that long ago, obviously without success for NuSphere, which makes it even more irrelevant. --88.130.78.184 (talk) 06:10, 10 February 2012 (UTC)
Sorry, I am not native English speaker. This meant to be in past tense. But this case was real danger. We in MySQL were seriously worried and as much I know Nusphere just didn't knew we had VC and CEO Marten Mickos came back from meeting with them telling we got $500,000 budget for legal costs. Without this most of Open Source projects would die trying to visit court on opposite side of world. And if something happened long time, doesn't make it irrelevant anyhow.

I reverted your chages because I have needed proof and will link to it. If you think material in unsourced, mark it that way, do not remove it. Tõnu Samuel (talk) 06:47, 10 February 2012 (UTC)

Merging small sections

The article has too many small sections with non-standard headers. Can you recommend a way to merge these sections into larger groups?

  • Uses -- talks a little about the users. already covered in lead.  Done
  • Distinguishing features -- "which some other RDBMS systems may not".. MAY NOT? then why separate that from "Features"?  Done
  • Limitations -- can this be placed under a "Criticisms" section?
  • Future releases -- shouldn't this be merged with the "Product versions" section? What makes the "future releases" special?  Done
  • Licensing and support -- somehow merge with corporate info?  Done
  • Conflict with NuSphere -- can this be placed along with the Forks?  Done
  • Forks -- "Forks"? means nothing to most people. can this be placed under the section that talks of MariaDB and the NuSphere matter and everything?  Done

Looking forward to improving this article. Thanks for any help. -- Tom Jenkins (reply) 10:58, 15 August 2012 (UTC)

I've corrected most of the flaws listed above, and merged a lot of small sections into larger ones. Notable merges include the History section, the Interfaces section (programming & frontends) and the Community section (support & forks). I hope everything looks fine. -- Tom Jenkins (reply) 04:41, 5 September 2012 (UTC)

.sock

New users are completely unaware of the significance of mysql.sock.

There should be an explanation in this article. — Preceding unsigned comment added by 66.90.167.171 (talk) 06:41, 11 March 2013 (UTC)

Wikipedia is not a manual Hcobb (talk) 11:22, 11 March 2013 (UTC)

Features

I think this phrase does not actively depict the current situation: "As of April 2009, MySQL offered MySQL 5.1 in two different variants: the open source MySQL Community Server and the commercial Enterprise Server. MySQL 5.5 is offered under the same licences. They have a common code base and include the following features:"

I would suggest that it be changed to something that talks about MySQL Server 5.6 + list Oracle's proprietary commercial extensions via plugin APIs (audit, connection pool, authentication). — Preceding unsigned comment added by 66.207.220.198 (talk) 19:41, 6 June 2013 (UTC)

LGPL client libraries and dual licensing

Should this be mentioned in the article: http://openquery.com/blog/mariadb-client-libraries-end-duallicensing

It's from another MySQL-forked project MariaDB, but works with MySQL, right? comp.arch (talk) 10:53, 1 October 2013 (UTC)

MySQL not licensed under GPL any more?

Oracle appears to have changed the licensing terms of MySQL, specifically v5.5.31, it's no longer licensed under GPLv2.[2] This requires clarifying.

"This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing."[3].

It was determined that the change in license on the MANUAL PAGES (and only these files were changes) was not intentional. The quoted changes have since been reverted to the original license. — Preceding unsigned comment added by 76.102.119.194 (talk) 22:50, 10 November 2013 (UTC)

--Diamonddavej (talk) 01:28, 19 June 2013 (UTC)

History section

I've added {{cn}} and {{dubious}} tags into the MySQL § History section, as ISAM isn't a low-level language, it's a method for indexing data, leading to an on-disk file format. Also, it's quite unclear which API was preserved in MySQL? — Dsimic (talk) 23:44, 15 January 2014 (UTC)

Most widely used or second most widely used open source database

I noticed that user Comp.arch changed the article to say MySQL was the second most widely used open source database, citing sqlite as #1. sqlite is however under public domain, which as far as I understand is "similar" but not "the same as" an OSI approved license (see FAQ here). For this reason, I am going to revert the change pending discussion here. — Preceding unsigned comment added by Morgo (talk • contribs) 18:51, 24 March 2014 (UTC)

Hello there! Hm, that's a quite interesting remark, but I'd say that applying such a differentiation would be more of something that bean counters would usually do. :) — Dsimic (talk | contribs) 19:34, 25 March 2014 (UTC)
It's relevant, because this is the claim MySQL makes on its homepage. I have not made the change yet - maybe someone can provide an alternative wording that clarifies the nuance rather than having the two sources contradict each other? morgo (talk) 20:56, 25 March 2014 (UTC)

Missing version info

MySQL 5.6 is GA.

The first develoment milestone release (DMR) for MySQL 5.7 has been released.

Older versions which were never released as GA (cancelled):

  • MySQL 5.2
  • MySQL 5.4

83.84.221.58 (talk) 17:51, 21 June 2013 (UTC)

I think in the case of 5.4, superseded may be a better choice of words (6.0 = cancelled). I have tried to update content to mention 5.6 GA/5.7 GA. morgo (talk) 22:04, 25 March 2014 (UTC)

Command Line Interfaces

Under "interfaces", the command line interfaces are out of date. Maatkit is no longer in development, so text should be updated to mention Percona Toolkit. At the same time, I think it is important to add the MySQL utilities (official toolkit) and openark kit, as well as remove SymmetricDS and XtraBackup. Xtrabackup should be moved to another section (Backup) and include MySQL Enterprise Backup and Mysqldump. The current features list mentioned mysqlhotcopy, which is MyISAM-only (no longer the default). morgo (talk) 22:14, 25 March 2014 (UTC)

Programming Interfaces

The "programming" section under interfaces seems to describe Operating Systems which MySQL has been known to port to (this is covered in the Info Box with a source to the official supported platforms). To me, programming "interfaces" should be the drivers (or connectors as MySQL prefers to call them) - Connector/J, Connector/NET, Connector/ODBC, Connector/Python etc. A list are available on https://www.mysql.com/products/connector/ — Preceding unsigned comment added by Morgo (talk • contribs) 22:22, 25 March 2014 (UTC)

Intro issue

"...the world's second most[a] widely used[9][10] open-source relational database management system (RDBMS)."

MySQL is the most used open-source RDBMS, and the second most used RDBMS. — Preceding unsigned comment added by 32.213.129.199 (talk) 16:21, 30 October 2014 (UTC)

ACID Compliance

"ACID compliance when using InnoDB" on the page - ACID compliance is in question because of the following bug: [1] which is still not addressed to this day.

I would like to see this mentioned on the page.

Thanks.

Dan Serfaty (talk) 18:54, 4 December 2015 (UTC)

References

  1. ^ https://bugs.mysql.com/bug.php?id=61555

Version History Graph

It might me interesting to include a graph about version history: https://github.com/dveeden/mysql-history-graph

--Dveeden (talk) 09:15, 15 January 2013 (UTC)

I would also like to see this here. My only comment is that I feel it is more relevant to the "Community" section than the History section, since it shows the origins of the other distributions. I would suggest changing it so that there is only ever one "hard line" to an ancestor, and multiple soft lines. i.e. Percona Server 5.6 is a hardline to MySQL 5.6, not Percona Server 5.5. MariaDB 5.5 is also a hardline to MySQL 5.5. morgo (talk) 23:34, 25 March 2014 (UTC)
I've removed the exhaustive list of MySQL versions as it goes against WP:NOT, and no other major database page that I can find has a list like this. It just doesn't fit on the wikipedia page for the database, and is better served from the MySQL site if it's important information. Any other thoughts on the matter? q (talk) 04:50, 21 August 2016 (UTC)

AliSQL

AliSQL fork currently inherits Alibaba's contribution to WebScaleSQL, which is abandoned now. — Preceding unsigned comment added by Cvp16 (talk • contribs) 14:32, 13 December 2016 (UTC)

I'm not sure what that means for inclusion in this article, but anything you're writing about needs a reliable secondary source. --McGeddon (talk) 15:28, 13 December 2016 (UTC)

Forks vs Branches

I don't know if it's fair to call projects like MariaDB and especially Percona "forks." If a project continuously creates branches of the original source and modifies that, it is not really a fork, but a branch (or a series of branches). Drizzle was a true fork because it went its own way. MariaDB, with its emphasis on compatibility, seems more like a branch. I watched Monty giving a talk on YouTube (from 2010: https://www.youtube.com/watch?v=AL1l9Puh0sk) where he spends some time emphasizing MariaDB is not a fork, but a branch. Percona is just a series of branches. It's not really an independent fork in any sense. Doorzki (talk) 23:29, 29 December 2016 (UTC)

Hello fellow Wikipedians,

I have just modified 2 external links on MySQL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 18:48, 5 April 2017 (UTC)

Game o thrones

É tudo uma mentira essa vida — Preceding unsigned comment added by 201.6.231.100 (talk) 19:00, 11 September 2017 (UTC)

Hello fellow Wikipedians,

I have just modified 8 external links on MySQL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 12:57, 21 January 2018 (UTC)

Hello fellow Wikipedians,

I have just modified 3 external links on MySQL. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

  • If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
  • If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:22, 9 February 2018 (UTC) — Preceding unsigned comment added by 2A02:8109:10C0:9699:1863:3A75:A21A:E3E4 (talk) 20:49, 27 March 2018 (UTC)

MySQL currently used by Google?

Is there any source that MySQL is currently used by any of Google services or products? (or at least it was in the last year) — Preceding unsigned comment added by Saeed.gnu (talk • contribs) 06:31, 5 June 2018 (UTC)

"MySQL Server" or "MySQL server"?

This articles uses both "MySQL Server" or "MySQL server". Which one should it be?

--Mortense (talk) 01:23, 16 May 2020 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:MySQL/Archive_2&oldid=1137029352"