Addshore added a comment.

  I managed to reproduce on https://www.wikidata.org/wiki/Q4115189 with `P195` 
in 
https://www.wikidata.org/w/index.php?title=Q4115189&diff=1078162868&oldid=1077776085
  
  With some debugging I found that:
  
  FullEntityParserOutputGenerator::getEntityInfoid is correctly given Q985852 
and `P195` and en for the fallback chain
  And the returning value includes the label "collection" which is what we 
would epxect to see in the rendered page.
  
    
{"P195":{"labels":{"en":{"language":"en","value":"collection"}},"descriptions":{"en":{"language":"en","value":"art,
 museum, archival, or bibliographic collection the subject is part 
of"}}},"Q985852":{"labels":{"en":{"language":"en","value":"Fu"}},"descriptions":{"en":{"language":"en","value":"Chinese
 surname \u5085"}}}}
  
  However StatementGroupListView incorrectly renders the snippet of HTML for 
the statement group list:
  
    Wikibase\View\StatementGroupListView::getHtml $statementsHtml (new bit) 
<div class="wikibase-statementgroupview" id="P195" data-property-id="P195">
    <div class="wikibase-statementgroupview-property">
    <div class="wikibase-statementgroupview-property-label" dir="auto"><a 
title="Property:P195" href="/wiki/Property:P195">P195</a></div>
    </div>
    <div class="wikibase-statementlistview">
    <div class="wikibase-statementlistview-listview">
    <div id="Q4115189$3d46867c-48a2-974a-5992-54592b37ac87" 
class="wikibase-statementview 
wikibase-statement-Q4115189$3d46867c-48a2-974a-5992-54592b37ac87 wb-normal">
  
  This uses a propertyIdFormatter which is a 
DispatchingEntityIdHtmlLinkFormatter.
  Which when called with `P195` is what gives us the wrong inner HTML snippet.
  
    <a title="Property:P195" href="/wiki/Property:P195">P195</a>
  
  The inner formatter that appears to always be used here is a 
`Wikibase\Lib\Formatters\LabelsProviderEntityIdHtmlLinkFormatter`
  When LabelsProviderEntityIdHtmlLinkFormatter::formatEntityId is called 
lookupEntityLabel returns null for `P195` resulting in the HTML we have already 
seen above.
  
  
Wikibase\DataModel\Services\EntityId\EntityIdLabelFormatter::lookupEntityLabel 
lookup class Wikibase\Lib\Store\LanguageFallbackLabelDescriptionLookup for 
entity `P195`
  Only Q985852 appears to get a CachingFallbackLabelDescriptionLookup here, 
which is the item that is the value for the statement that I am investigating..
  F31478751: image.png <https://phabricator.wikimedia.org/F31478751>
  This is worth investigating afterwards as per T201838 
<https://phabricator.wikimedia.org/T201838> the properties should also be using 
the caching layer introduced during one of the previous wb_terms trailblazes.
  My logging result was P9897 <https://phabricator.wikimedia.org/P9897> when 
using adhoc logging P9898 <https://phabricator.wikimedia.org/P9898>...
  
  LanguageFallbackLabelDescriptionLookup internally uses a 
`Wikibase\Lib\Store\DispatchingTermBuffer` for `P195`
  This buffer uses > 
`Wikibase\DataAccess\ByTypeDispatchingPrefetchingTermLookup` which uses a 
`Wikibase\Lib\Store\Sql\Terms\PrefetchingPropertyTermLookup`
  
  PrefetchingPropertyTermLookup::prefetchTerms seems to correctly query the DB 
returning a bunch of rows like:
  
    {"wbpt_property_id":"195","wbpt_term_in_lang_id":"27543"}
    {"wbpt_property_id":"195","wbpt_term_in_lang_id":"27542"}
    {"wbpt_property_id":"195","wbpt_term_in_lang_id":"27541"}
  
  Which are stored and then, termIdsResolver->resolveGroupedTermIds is called 
to resolve these wbpt_term_in_lang_id fields, using a 
`Wikibase\Lib\Store\Sql\Terms\DatabaseTermIdsResolver` (an in memory one is 
also available)
  
  It was at this point that I decided to have a quick look in the DB, as I hve 
already gone down this code path rabbit hole for quite a while, and we are 
nearly at the DB..
  
  The following query should select the en label for the property... But it 
returned 0 results.
  
    SELECT
      wbpt_property_id as id,
      wby_name as type,
      wbxl_language as language,
      wbx_text as text
    FROM wbt_property_terms
    LEFT JOIN wbt_term_in_lang ON wbpt_term_in_lang_id = wbtl_id
    LEFT JOIN wbt_type ON wbtl_type_id = wby_id
    LEFT JOIN wbt_text_in_lang ON wbtl_text_in_lang_id = wbxl_id
    LEFT JOIN wbt_text ON wbxl_text_id = wbx_id
    WHERE wbpt_property_id = 195
    AND wby_name = 'label'
    AND wbxl_language = 'en';
  
  Removing the language and selecting some fields again shows us that there is 
some odd stuff in the DB..
  Full paste at P9903 <https://phabricator.wikimedia.org/P9903>
  The weirdest rows are extracted below:
  
    
+---------+------------------+----------------------+-----------+--------------+----------------------+--------+----------+-----------+---------------+--------------+--------+----------+
    | wbpt_id | wbpt_property_id | wbpt_term_in_lang_id | wbtl_id   | 
wbtl_type_id | wbtl_text_in_lang_id | wby_id | wby_name | wbxl_id   | 
wbxl_language | wbxl_text_id | wbx_id | wbx_text |
    
+---------+------------------+----------------------+-----------+--------------+----------------------+--------+----------+-----------+---------------+--------------+--------+----------+
    |   27557 |              195 |                27407 |     27407 |           
 1 |                27238 |      1 | label    |      NULL | NULL          |     
    NULL |   NULL | NULL     |
    |  313554 |              195 |            273046250 | 273046250 |           
 1 |            263833266 |      1 | label    | 263833266 | fr            |     
87612649 |   NULL | NULL     |
    |  313556 |              195 |            275677887 | 275677887 |           
 1 |            274119666 |      1 | label    | 274119666 | en-gb         |     
87612649 |   NULL | NULL     |
    |  313557 |              195 |            275677888 | 275677888 |           
 1 |            274119667 |      1 | label    | 274119667 | ia            |     
87612649 |   NULL | NULL     |
    |  313558 |              195 |            275677889 | 275677889 |           
 1 |            274119668 |      1 | label    | 274119668 | sco           |     
87612649 |   NULL | NULL     |
    
+---------+------------------+----------------------+-----------+--------------+----------------------+--------+----------+-----------+---------------+--------------+--------+----------+
  
  So conclusion of my first look at this is it is probably nothing to do with 
the reading and rendering side of the stack, but to do with the writing side of 
the stack.
  This explains why purging doesn't really solve the problem.
  
  Making an edit to the property 
https://www.wikidata.org/w/index.php?title=Property:P195&diff=1078226992&oldid=1070123486
 which would write to the terms stores again correctly populates the table and 
then purging my test item Q4115189 that had the duff property rendered on it 
fixed the issue for `P195`.
  
  I'll continue investigating the writing side now..

TASK DETAIL
  https://phabricator.wikimedia.org/T237984

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: abian, JAnD, Ash_Crow, Addshore, PKM, Moebeus, alaa_wmde, VIGNERON, 
Aklapper, Lydia_Pintscher, Ladsgroup, Lea_Lacroix_WMDE, Iflorez, darthmon_wmde, 
Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, 
rosalieper, Scott_WUaS, Jonas, Wikidata-bugs, aude, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Reply via email to