Last modified: 2006-02-25 00:09:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1065 - Inclusions should not be stored in the generic 'links' table
Inclusions should not be stored in the generic 'links' table
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Templates (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 2409 (view as bug list)
Depends on:
Blocks: 734 939 983 1337
  Show dependency treegraph
 
Reported: 2004-12-11 00:23 UTC by Rowan Collins [IMSoP]
Modified: 2006-02-25 00:09 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Rowan Collins [IMSoP] 2004-12-11 00:23:33 UTC
It has been mentioned in various places that the current practice of storing
template inclusions in the 'links' table is unhelpful at best. It is at least
partly the cause of all the bugs I've marked as depending on this one, and
perhaps of many more.

I note that there has also been a suggestion that rather than creating a new
'templatelinks' / '{trans|in}clusionlinks' table, we should actually *merge* the
various existing links tables ('imagelinks', 'categorylinks', etc) and mark them
with a 'linktype' field instead.

Either way, I just thought it would be useful to track what issues depend on
such a change.
Comment 1 Wikipedia:en:User:Paddu 2004-12-16 17:30:44 UTC
Does this block bug 572 as bug 734 comment 4 seems to imply?
Comment 2 Brion Vibber 2004-12-16 17:58:17 UTC
(In reply to comment #1)
> Does this block bug 572 as bug 734 comment 4 seems to imply?

It shouldn't, except for those which are not in the template: namespace (bug 734) or regarding changes to 
templates used in templates used in some page.
Comment 3 Wikipedia:en:User:Paddu 2004-12-16 19:15:59 UTC
Should an attempt to transclude an inexistent page result in adding it to the
"normal links table" or the "transcluding pages table"?
Comment 4 Rowan Collins [IMSoP] 2004-12-16 20:22:51 UTC
(In reply to comment #3)
> Should an attempt to transclude an inexistent page result in adding it to the
> "normal links table" or the "transcluding pages table"?

A good question - the display in such a case is as a "red link", which are
normally stored in the brokenlinks table; are they, in fact, stored in
brokenlinks now? Perhaps if the "single table with 'link_type' field" approach
were taken, there could be a 'link_is_broken' flag; I'm thinking this would be
handy for categories as well - allowing an easy query for "category containing
pages but no introductory text". 

Which brings us to another question about this idea: if I understand correctly,
some of the '*links' tables use ID->name pairs, and others use ID->ID; if there
are good reasons for this difference, there will presumably need to be at least
2 tables, one of each type. I presume this is to do with efficiency or somesuch,
since *all* links are actually to "the page with this name" not "this page
whatever it's name is", so ID->ID pairs have to be carefully kept up to date;
and obviously, any broken link can't refer to an ID, so that may put paid to the
idea of "WHERE link_type=<category> AND link_is_broken=1" etc.
Comment 5 Wikipedia:en:User:Paddu 2004-12-16 20:42:05 UTC
DISCLAIMER: I know absolutely nothing about MediaWiki, so if the following is
useless gibberish, please ignore.

I presume by ID you mean oldid, which I hear is not permanent, and may change on
deleting & undeleting the page. Hence any ID->ID tables must be changed to
ID->name. Which tables are those? Shouldn't a separate bug be filed for changing
them to ID->name (or at least augmenting them with another table that is
ID->name plus lot of ugly processing to decide which of the two tables must be
used at any time, since ID->ID may not always be up-to-date). Also what happened
to the fact that latest versions of pages have no IDs?
Comment 6 Rowan Collins [IMSoP] 2004-12-16 21:17:26 UTC
(In reply to comment #5)
> DISCLAIMER: I know absolutely nothing about MediaWiki, so if the following is
> useless gibberish, please ignore.

I prefer to spread the knowledge. ;)

> I presume by ID you mean oldid, which I hear is not permanent, and may change on
> deleting & undeleting the page. [...] Also what happened
> to the fact that latest versions of pages have no IDs?

No, this is not the 'old_id': each page has a 'cur_id' which refers to "whatever
the latest version of this page is" - e.g. the main page has cur_id=1; if
someone edits it, cur_id=1 still refers to the *current* main page, not some old
version of the main page. At the moment, the current content of every page is
stored in one database table, and all old versions in another; each edit creates
a new old version (with a new old_id) but the current version (with its cur_id)
is just over-written with what is now current. This will change "soon", so that
we can say "what is the current revision for page_id=1" in the same way we
already say "what old revisions are there for page_id=1".

If you think about it, this makes sense: a link is not to a page *at the time
you created the link*, but to the page in general, whenever you feel like
following the link.
Comment 7 Wikipedia:en:User:Paddu 2004-12-17 17:01:30 UTC
OK, so does that mean ID->ID links always point to the "latest name" when pages
get moved? (I assume moving a page assigns the new name to the same ID but
creates another ID for the old name.) In that case probably ID->ID links make
more sense than ID->name.
Comment 8 Rowan Collins [IMSoP] 2004-12-17 17:28:36 UTC
(In reply to comment #7)
> (I assume moving a page assigns the new name to the same ID but
> creates another ID for the old name.) 

Yes, I believe that's how it works. The redirect at the old name is technically
a new page.

> In that case probably ID->ID links make more sense than ID->name.

Not really, because the text of the article still contains a link to the old
name, not the new one. So presumably all the entries in the links table get
changed to the new ID, because that's the article the links actually point to
(the redirect, at the old name). Hence why I guessed it was something to do with
efficiency, because I can't see how else it makes sense.
Comment 9 Brion Vibber 2004-12-17 19:40:32 UTC
(In reply to comment #8)
> So presumably all the entries in the links table get
> changed to the new ID, because that's the article the links actually point to
> (the redirect, at the old name).

Right. This is a pain in the butt, as potentially a very large number of entries may need to be updated. At 
some point we will probably dump the separate links and brokenlinks tables and have a single id -> name 
space which can be left peacefully intact.
Comment 10 Brion Vibber 2005-06-17 19:19:45 UTC
*** Bug 2409 has been marked as a duplicate of this bug. ***
Comment 11 lɛʁi לערי ריינהארט 2005-06-19 05:28:52 UTC
Hallo!
I do not know if it is relevant here.
http://jadesukka.homelinux.org:8180/mediawiki15c/index.php?title=Betawiki:Special_pages&action=purge#see_also
does neither show [[Template:Specialpages/list_(template)]] nor
[[Template:Specialpages/list_(temp)]] as "Templates used on this page:" used in
{{Specialpages/list_(template)|Specialpages/list_(temp)}}.
Neither in edit nor in preview.
Regards Reinhardt [[user:gangleri]]
Comment 12 lɛʁi לערי ריינהארט 2005-06-19 12:55:19 UTC
bug 2456: "Templates used on this page:" is not updated (properly) while a page
is changed
refers here
it is neither clear how are dependencies nor what should be done first
Comment 13 Tim Starling 2006-02-25 00:09:11 UTC
This is fixed in CVS for release in 1.6. 

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links