Page MenuHomePhabricator

database error: Duplicate entry for key 'pp_page_propname'
Closed, ResolvedPublic

Description

Hello Cindy,

we've had a database error that was difficult to reproduce. Now I've got one error catched with SQL error reporting enabled. There seems to be a problem with a non-unique primary key?

This happens -sometimes- when saving a new page that uses a semantic title.

Es ist ein Datenbankabfragefehler aufgetreten. Dies könnte auf einen Fehler in der Software hindeuten.

    Abfrage:
    INSERT INTO `page_props` (pp_page,pp_propname,pp_value) VALUES ('2684','displaytitle','E')
    Funktion: SemanticTitle::setDisplayTitle
    Fehler: 1062 Duplicate entry '2684-displaytitle' for key 'pp_page_propname' (localhost)

Translated: ~ A database error occured. This may indicate a bug in the software.

I'm using:
MediaWiki 1.25.5
PHP 5.5.9-1ubuntu4.14 (apache2handler)
MySQL 5.5.47-0ubuntu0.14.04.1

Semantic Title 3.1

Event Timeline

Fannon created this task.Mar 1 2016, 1:32 PM
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptMar 1 2016, 1:32 PM
Fannon updated the task description. (Show Details)Mar 1 2016, 1:34 PM
Fannon added a subscriber: cicalese.

Yes, that is a transient error that I have seen since converting SemanticTitle to use display title under the hood. It has to do with the way the parser sets page properties. SemanticTitle really should not be trying to set display title page property itself, since the parser owns page properties. I initially thought this was a one time problem that could occur when upgrading to the new version of the extension. I was not aware that it is an on-going problem for new pages.

Fortunately, there is a quick fix: you can change from setting the display title with a property to using {{DISPLAYTITLE:...}} to set it. You would also need to change your configuration to remove $wgSemanticTitleProperties. You could obviously continue to set the property if you use it for other purposes.

I'm actually considering removing the feature of setting the display title from a Semantic MediaWiki property or Cargo field from an upcoming release of SemanticTitle. It duplicates the functionality of the {{DISPLAYTITLE:...}} magic word that is built into MediaWiki - and it duplicates it in an inferior manner. SemanticTitle would still retain the functionality to change the link text on a page to the display title (unless/until I can get that functionality accepted into MediaWiki core, disabled by default with a configuration variable) and the #semantic-title parser function. I welcome your feedback on this potential change. I would make this change when I release a new version of SemanticTitle to work with MediaWiki 1.27. I had a new PageProps class merged into MediaWiki core recently, which will improve SemanticTitle's read access to the display title page property.

Fannon triaged this task as Normal priority.Mar 1 2016, 4:35 PM

Hello Cindy,

thanks for your precise explanation!

Yes, I've already thought about the "duplication" of the Semantic Title Property and the displaytitle magic word when reading the related issues on Github.

I agree that it would be a cleaner and more consistent to use the magic word for setting the displaytitle, and SMW automatically providing the semantic property if a displaytitle is detected.

Really looking forward to the new releases and your issues beeing merged in!

Best,
Simon

Fannon added a comment.Mar 2 2016, 1:11 PM

Hi,

I've tryed to follow your proposal and use {{DISPLAYTITLE:}} to set the new title, but I also need to set $wgRestrictDisplayTitle = false;.

The official documentation:

The value must be equivalent to the default title: only capitalization changes to certain parts of the title (not all) and replacing spaces with underscores are allowed (this can be changed with $wgRestrictDisplayTitle).

Oh, yes, I'm so sorry - I should have mentioned that. You need to set:

$wgAllowDisplayTitle = true;
$wgRestrictDisplayTitle = false;

to use the {{DISPLAYTITLE:...}} approach.

Fannon closed this task as Resolved.Mar 14 2016, 5:06 PM