diff options
Diffstat (limited to 'docs/html/dbdoc.html')
| -rw-r--r-- | docs/html/dbdoc.html | 60 |
1 files changed, 29 insertions, 31 deletions
diff --git a/docs/html/dbdoc.html b/docs/html/dbdoc.html index 8e0109d0d..82548422b 100644 --- a/docs/html/dbdoc.html +++ b/docs/html/dbdoc.html @@ -108,7 +108,7 @@ NAME="dbdoc" ><P >But Certain Death speaks up -- a tiny voice, from the dark corners of the conference room. "I have a concern," the voice hisses from the - darkness, "about the use of the word 'verified'.</P + darkness, "about the use of the word 'verified'."</P ><P >The room, previously filled with happy chatter, lapses into reverential silence as Certain Death (better known as the Vice President @@ -135,7 +135,7 @@ CLASS="section" ><H2 CLASS="section" ><A -NAME="AEN2091" +NAME="AEN2190" ></A >B.2.1. Bugzilla Database Basics</H2 ><P @@ -154,14 +154,12 @@ CLASS="QUOTE" >"tinyint"</SPAN > - entry in MySQL. I recommend you refer to the MySQL documentation, - available at + entry in MySQL. I recommend you refer to the <A -HREF="http://www.mysql.com/doc.html" +HREF="http://www.mysql.com/documentation/" TARGET="_top" ->MySQL.com</A +>MySQL documentation</A > - . Below are the basics you need to know about the Bugzilla database. Check the chart above for more details.</P ><P @@ -205,7 +203,7 @@ HREF="http://www.mysql.com/php/manual.php3?section=Privilege_system" TARGET="_top" >MySQL searchable documentation</A ->. +>. </P ></LI ><LI @@ -251,7 +249,7 @@ CLASS="section" ><H3 CLASS="section" ><A -NAME="AEN2118" +NAME="AEN2217" ></A >B.2.1.1. Bugzilla Database Tables</H3 ><P @@ -322,14 +320,14 @@ CLASS="programlisting" ><P CLASS="literallayout" ><br> - Here's an overview of what each table does. Most columns in each table have<br> + Here's an overview of what each table does. Most columns in each table have<br> descriptive names that make it fairly trivial to figure out their jobs.<br> <br> -attachments: This table stores all attachments to bugs. It tends to be your<br> +attachments: This table stores all attachments to bugs. It tends to be your<br> largest table, yet also generally has the fewest entries because file<br> attachments are so (relatively) large.<br> <br> -bugs: This is the core of your system. The bugs table stores most of the<br> +bugs: This is the core of your system. The bugs table stores most of the<br> current information about a bug, with the exception of the info stored in the<br> other tables.<br> <br> @@ -337,26 +335,26 @@ bugs_activity: This stores information regarding when -- a history file.<br> <br> cc: This tiny table simply stores all the CC information for any bug which has<br> -any entries in the CC field of the bug. Note that, like most other tables in<br> +any entries in the CC field of the bug. Note that, like most other tables in<br> Bugzilla, it does not refer to users by their user names, but by their unique<br> userid, stored as a primary key in the profiles table.<br> <br> components: This stores the programs and components (or products and<br> -components, in newer Bugzilla parlance) for Bugzilla. Curiously, the "program"<br> +components, in newer Bugzilla parlance) for Bugzilla. Curiously, the "program"<br> (product) field is the full name of the product, rather than some other unique<br> identifier, like bug_id and user_id are elsewhere in the database.<br> <br> dependencies: Stores data about those cool dependency trees.<br> <br> -fielddefs: A nifty table that defines other tables. For instance, when you<br> +fielddefs: A nifty table that defines other tables. For instance, when you<br> submit a form that changes the value of "AssignedTo" this table allows<br> translation to the actual field name "assigned_to" for entry into MySQL.<br> <br> -groups: defines bitmasks for groups. A bitmask is a number that can uniquely<br> -identify group memberships. For instance, say the group that is allowed to<br> +groups: defines bitmasks for groups. A bitmask is a number that can uniquely<br> +identify group memberships. For instance, say the group that is allowed to<br> tweak parameters is assigned a value of "1", the group that is allowed to edit<br> users is assigned a "2", and the group that is allowed to create new groups is<br> -assigned the bitmask of "4". By uniquely combining the group bitmasks (much<br> +assigned the bitmask of "4". By uniquely combining the group bitmasks (much<br> like the chmod command in UNIX,) you can identify a user is allowed to tweak<br> parameters and create groups, but not edit users, by giving him a bitmask of<br> "5", or a user allowed to edit users and create groups, but not tweak<br> @@ -371,15 +369,15 @@ keywords: Unlike what you'd think, this table  associated with which bug id's.<br> <br> logincookies: This stores every login cookie ever assigned to you for every<br> -machine you've ever logged into Bugzilla from. Curiously, it never does any<br> -housecleaning -- I see cookies in this file I've not used for months. However,<br> +machine you've ever logged into Bugzilla from. Curiously, it never does any<br> +housecleaning -- I see cookies in this file I've not used for months. However,<br> since Bugzilla never expires your cookie (for convenience' sake), it makes<br> sense.<br> <br> longdescs: The meat of bugzilla -- here is where all user comments are stored!<br> You've only got 2^24 bytes per comment (it's a mediumtext field), so speak<br> sparingly -- that's only the amount of space the Old Testament from the Bible<br> -would take (uncompressed, 16 megabytes). Each comment is keyed to the<br> +would take (uncompressed, 16 megabytes). Each comment is keyed to the<br> bug_id to which it's attached, so the order is necessarily chronological, for<br> comments are played back in the order in which they are received.<br> <br> @@ -387,12 +385,12 @@ milestones: Interesting that milestones are assoc in this table, but Bugzilla does not yet support differing milestones by<br> product through the standard configuration interfaces.<br> <br> -namedqueries: This is where everybody stores their "custom queries". Very<br> +namedqueries: This is where everybody stores their "custom queries". Very<br> cool feature; it beats the tar out of having to bookmark each cool query you<br> construct.<br> <br> products: What products you have, whether new bug entries are allowed for the<br> -product, what milestone you're working toward on that product, votes, etc. It<br> +product, what milestone you're working toward on that product, votes, etc. It<br> will be nice when the components table supports these same features, so you<br> could close a particular component for bug entry without having to close an<br> entire product...<br> @@ -427,7 +425,7 @@ mysql> show columns from table;<br> mysql> select * from table;<br> <br> -- note: this is a very bad idea to do on, for instance, the "bugs" table if<br> -you have 50,000 bugs. You'll be sitting there a while until you ctrl-c or<br> +you have 50,000 bugs. You'll be sitting there a while until you ctrl-c or<br> 50,000 bugs play across your screen.<br> <br> You can limit the display from above a little with the command, where<br> @@ -440,7 +438,7 @@ mysql> select * from table where (column mysql> select * from table where (column != "some info");<br> <br> Let's take our example from the introduction, and assume you need to change<br> -the word "verified" to "approved" in the resolution field. We know from the<br> +the word "verified" to "approved" in the resolution field. We know from the<br> above information that the resolution is likely to be stored in the "bugs"<br> table. Note we'll need to change a little perl code as well as this database<br> change, but I won't plunge into that in this document. Let's verify the<br> @@ -451,10 +449,10 @@ mysql> show columns from bugs<br> (exceedingly long output truncated here)<br> | bug_status| enum('UNCONFIRMED','NEW','ASSIGNED','REOPENED','RESOLVED','VERIFIED','CLOSED')||MUL | UNCONFIRMED||<br> <br> - Sorry about that long line. We see from this that the "bug status" column is<br> + Sorry about that long line. We see from this that the "bug status" column is<br> an "enum field", which is a MySQL peculiarity where a string type field can<br> -only have certain types of entries. While I think this is very cool, it's not<br> -standard SQL. Anyway, we need to add the possible enum field entry<br> +only have certain types of entries. While I think this is very cool, it's not<br> +standard SQL. Anyway, we need to add the possible enum field entry<br> 'APPROVED' by altering the "bugs" table.<br> <br> mysql> ALTER table bugs CHANGE bug_status bug_status<br> @@ -470,15 +468,15 @@ mysql> show columns from bugs;<br> <br> you'll see that the bug_status field has an extra "APPROVED" enum that's<br> available! Cool thing, too, is that this is reflected on your query page as<br> -well -- you can query by the new status. But how's it fit into the existing<br> +well -- you can query by the new status. But how's it fit into the existing<br> scheme of things?<br> Looks like you need to go back and look for instances of the word "verified"<br> in the perl code for Bugzilla -- wherever you find "verified", change it to<br> "approved" and you're in business (make sure that's a case-insensitive search).<br> Although you can query by the enum field, you can't give something a status<br> -of "APPROVED" until you make the perl changes. Note that this change I<br> +of "APPROVED" until you make the perl changes. Note that this change I<br> mentioned can also be done by editing checksetup.pl, which automates a lot of<br> -this. But you need to know this stuff anyway, right?<br> +this. But you need to know this stuff anyway, right?<br> </P ></DIV ></DIV |