Bug #33236 Term "Primary and Unique Index constraints" doesn't make sense
Submitted: 14 Dec 2007 8:37 Modified: 19 Dec 2007 15:31
Reporter: Roland Bouman Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Documentation Severity:S3 (Non-critical)
Version:all OS:Any
Assigned to: Paul DuBois CPU Architecture:Any

[14 Dec 2007 8:37] Roland Bouman
Description:
http://dev.mysql.com/doc/refman/5.1/en/constraint-primary-key.html

uses the term "PRIMARY KEY and UNIQUE Index Constraints". This term is strange to say at least. 

While it is true that MySQL internally doesn't have separate objects for PRIMARY KEY and UNIQUE constraints, on the general level that forms the context of chapter 1 (i.e. characterization of the product, comparison to other products and standards) it is quite strange to use this term "...index constraints".

An index is an access structure - no more, no less. A constraint is a rule - something that defines the integrity of the database. The fact that constraints may be implemented using indexes does not justify the invention of a new term "index constraints". On this level, the index is just an implementation detail of the constraint that is in no way relevant for the subject.

The text also uses the term "key violation" in a number of places. This is an equally confusing term because in MySQL the KEY keyword is  synonymous with INDEX. Here too, it should read "constraint violation" rather than "key violation". 

How to repeat:
http://dev.mysql.com/doc/refman/5.1/en/constraint-primary-key.html

Suggested fix:
Please don't use the term "PRIMARY KEY and UNIQUE Index Constraints". Use: "PRIMARY KEY and UNIQUE Constraints" instead.

Also, don't use the term "key violation", use: "constraint violation" instead.
[14 Dec 2007 22:06] Peter Gulutzan
Roland is correct; MySQL shouldn't say "violate a key".

I don't think it's necessarily wrong to say "unique-key
constraint" or "unique-index constraint" (that would be
"a constraint supported via a unique index" rather than
"a UNIQUE constraint", but the distinction is nugatory.)
But it's necessary to fix what's really wrong.

The first sentence is too specific anyway because other
statements besides INSERT or UPDATE (e.g. ALTER, REPLACE)
could cause the errors. And they don't cause the violation,
because there's an error -- they fail to cause it.
I suggest changing the sentence to

Normally errors occur for data-change statements (such as
INSERT or UPDATE) that would violate primary-key, unique-key,
or foreign key constraints.

The second paragraph is misleading anyway, like most passages
relating to IGNORE. I suggest changing the paragraph to:

"MySQL supports an IGNORE keyword for INSERT, UPDATE, REPLACE,
etc. If you use it, MySQL ignores primary-key or unique-key
violations and continues processing with the next row.
See Section 11.2.4, “INSERT Syntax”, Section 11.2.10, “UPDATE Syntax”,
and so on."
[19 Dec 2007 15:31] Paul DuBois
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.

I have updated the section based on Peter's corrections.
Roland, Peter, thanks.