For information about the MediaWiki database layout, such as a
description of the tables and their contents, please see:
- http://meta.wikimedia.org/wiki/Help:Database_layout
+ http://www.mediawiki.org/wiki/Manual:Database_layout
http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/tables.sql?view=markup
To make a read query, something like this usually suffices:
-$dbr =& wfGetDB( DB_SLAVE );
+$dbr = wfGetDB( DB_SLAVE );
$res = $dbr->select( /* ...see docs... */ );
while ( $row = $dbr->fetchObject( $res ) ) {
...
For a write query, use something like:
-$dbw =& wfGetDB( DB_MASTER );
+$dbw = wfGetDB( DB_MASTER );
$dbw->insert( /* ...see docs... */ );
We use the convention $dbr for read and $dbw for write to help you keep
difficult.
In addition to this, MediaWiki attempts to ensure that the user sees
-events occuring on the wiki in chronological order. A few seconds of lag
+events occurring on the wiki in chronological order. A few seconds of lag
can be tolerated, as long as the user sees a consistent picture from
subsequent requests. This is done by saving the master binlog position
in the session, and then at the start of each request, waiting for the
enclose small groups of queries in their own transaction. Use the
following syntax:
-$dbw =& wfGetDB( DB_MASTER );
+$dbw = wfGetDB( DB_MASTER );
$dbw->immediateBegin();
/* Do queries */
$dbw->immediateCommit();
the list is almost always going to have just one item on it, if
that, so it's not worth the trouble.
+
+Since 1.6 there is a 'job queue' in the jobs table, which is used
+to update link tables of transcluding pages after edits; this
+may be extended in the future to more general background tasks.
+
+Job queue items are fetched out of the queue and run either
+at a random rate during regular page views (by default) or by
+a batch process which can be run via maintenance/runJobs.php.
This is a brief overview of the new design.
+More thorough and up-to-date information is available on the documentation
+wiki at http://www.mediawiki.org/
+
Primary source files/objects:
index.php
don't involve their text, such as access rights.
Article
- Encapsulates access to the "cur" table of the database. The
+ Encapsulates access to the "page" table of the database. The
object represents a an article, and maintains state such as
text (in Wikitext format), flags, etc.
+ Revision
+ Encapsulates individual page revision data and access to the
+ revision/text/blobs storage system. Higher-level code should
+ never touch text storage directly; this class mediates it.
+
Skin
Encapsulates a "look and feel" for the wiki. All of the
functions that render HTML, and make choices about how to
of session variables are wsName, cookies wcName, and form field
values wpName ("p" for "POST").
- - Be kind to your release manager and don't use CVS keywords (Id,
- Revision, etc.) to mark file versions. They make merging code
- between different branches a pain for CVS, and are kind of sketchy
- for versions after that. (Yes, you can use the '-kk' flag so that
- merges ignore keywords, but that messes up binary files. See
- https://www.cvshome.org/docs/manual/cvs-1.11.18/cvs_5.html#SEC64).
-
-
-
rules, it is possible to have articles with colons in their
names. "E. Coli 0157:H7" is a valid title, as is "2001: A Space
Odyssey", because "E. Coli 0157" and "2001" are not valid
-interwikis or namespaces. Likewise, ":de:name" is a link to
-the article "de:name"--even though "de" is a valid interwiki,
-the initial colon stops all prefix matching.
+interwikis or namespaces.
+
+It is not possible to have an article whose bare name includes
+a namespace or interwiki prefix.
+
+An initial colon in a title listed in wiki text may however
+suppress special handling for interlanguage links, image links,
+and category links.
Character mapping rules: Once prefixes have been stripped, the
rest of the title processed this way: spaces and underscores are
alone; it will use spaces only when attached to the text title.
getArticleID() needs some explanation: for "internal" articles,
-it should return the "cur_id" field if the article exists, else
+it should return the "page_id" field if the article exists, else
it returns 0. For all external articles it returns 0. All of
the IDs for all instances of Title created during a request are
-cached, so they can be looked up wuickly while rendering wiki
+cached, so they can be looked up quickly while rendering wiki
text with lots of internal links.