Edgewall Software

Opened 14 years ago

Closed 14 years ago

Last modified 11 years ago

#4112 closed defect (fixed)

wiki link displayed as missing when version 1 is deleted

Reported by: Matt Shin Owned by: Jonas Borgström
Priority: normal Milestone: 0.10.3
Component: wiki system Version: 0.10
Severity: normal Keywords:
Cc: peter.bruin@… Branch:
Release Notes:
API Changes:
Internal Changes:


Since upgrading to 0.10, it appears that if we link to a wiki page with no version 1, the link will be displayed with a ? at the end, and the wiki page will no longer be listed in the TitleIndex. (Hence, it appears to be missing, when it is actually still there.)

Attachments (0)

Change History (16)

comment:1 by anonymous, 14 years ago

It looks like this "bug" was introduced by the "optimization" at [3875].

comment:2 by simon-code@…, 14 years ago

Well, at least it appears in 'Index by Date' :-)

As long as any version can be deleted - including version 1 - it is not really safe to presume a certain version number exists.

comment:3 by simon-code@…, 14 years ago

Ah. Just noticed #1114, and that the functionality to remove any revision is no longer available. So for recently created projects, the revision=1 will hold true.

That means I have to figure out a way to 'clean up' my old revision list in various projects that are much older than 0.10, as many of them have a number of wiki pages with 'holes' in them - including missing revision 1. I need to basically 'compact' the revision numbers for all existing pages, so that they all start with 1 and move up to the number of revisions in a continuous range.

Ideally such changes as in #1114 should include cleanup as part of trac-admin upgrade, and be executed for installations when such a feature is introduced.

Someone want to help out making the necessary SQL to fix this?

comment:4 by Christian Boos, 14 years ago

Well, I'd rather fix r3875 than adding overly complex code to compact version numbers (as this could theoretically happen anytime, etc.)

in reply to:  4 comment:5 by Matthew Good, 14 years ago

Replying to cboos:

Well, I'd rather fix r3875 than adding overly complex code to compact version numbers (as this could theoretically happen anytime, etc.)

Yeah, compacting version numbers would also impact links to specific version of pages, so I don't think that's an option. I think for 0.10.2 we'll just need to revert r3875, unless the performance has been a serious problem. Then we could try adding an index on "name" for 0.11 if that improves the performance.

Jonas, any suggestions?

comment:6 by simon-code@…, 14 years ago

I have no strong feelings about the final solution as long as it will work for all projects. I see the point of optimising the index creation, and maybe a modified solution might be to make sure that the lowest version is 1 and leave any other gaps as they are?

I am fixing my environments now regardless, and have this SQL to identify "offenders":

select name, min(version)
from wiki
group by name
having min(version) > 1
order by name;

Then I update records by setting version=1 for each record in the result.

comment:7 by PBruin, 14 years ago

Cc: peter.bruin@… added

comment:8 by Dave Matthews, 14 years ago

Is this likely to be fixed? It's easy enough for us to patch 0.10.3 to reverse [3875] for the moment. However, if it's not going to be fixed then we'll have to work out how to update our SQLite databases.


comment:9 by Christian Boos, 14 years ago

mgood agreed to backout r3875, so I think this is going to be fixed, it's only about who will do it ;)

comment:10 by Matthew Good, 14 years ago

Resolution: fixed
Status: newclosed

Ok, the changes from r3875 have been reverted in r4430 and r4431:4432.

comment:11 by Jonas Borgström, 14 years ago

This is unfortunate since this optimization reduced the query time from about 80ms to < 1ms on t.e.o IIRC. But I guess I'll have to figure out a better way to do this…

comment:12 by Christian Boos, 14 years ago

Maybe by adding some indexes on the wiki table? Currently, there's only one index on the time column.

comment:13 by Christian Boos, 14 years ago

oops, too fast, there's the key ('name', 'version')

So I wonder if having a dedicated index on 'name' would help.

comment:14 by Jonas Borgström, 14 years ago

Since a "SELECT DISTINCT" query needs to scan through all rows an index will not help. The only thing we can do is to find a way to limit the total number of rows to scan.

comment:15 by Christian Boos, 14 years ago

Ok, but anyway I wouldn't worry too much about this issue, as the current way of caching the list of all wiki pages is anyway a "hack", and a (IMO) correct approach to this problem has been described in TracDev/Proposals/Journaling.

comment:16 by zach@…, 11 years ago

On postgres "SELECT name FROM wiki GROUP BY name" is 3 times as fast as the select distinct query on my system.

This is pretty significant, as the query was taking ~400ms before I changed it. This may just be a postgres quirk though, and not apply to sqlite.

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.