So, am I to understand that wb_terms, wb_items_per_site, and probably others will also switch from numeric IDs to strings?
Am 09.08.2015 um 17:28 schrieb Maarten Dammers:
> Hi Marius,
> hoo schreef op 7-8-2015 om 19:55:
>> Hey folks,
>> we plan to drop the wb_entity_per_page table sometime soon, because
>> it is just not required (as we will likely always have a programmatic
>> mapping from entity id to page title) and it does not supported non
>> -numeric entity ids as it is now.
> In the past I was alway told to use the wb_entity_per_page table
> instead of doing page_title=CONCAT('Q', <id>). The Wikibase code used
> to contain warnings not to make this assumption. I don't know, they
> might still be there.
>> Due to this removing it is a blocker
>> for the commons metadata.
> That's unfortunate.
>> Is anybody using that for their tools (on tool labs)? If so, please
>> tell us so that we can give you instructions and a longer grace period
>> to update your scripts.
> Of the 117 Wikidata related sql queries that seem to be in my homedir,
> 48 of them use this table. Basically any Wikidata related tool that
> uses the sql database will break. What do you propose? That we start
> messing around with CONCAT()s in our SQL queries? Besides the hours of
> wasted volunteer time, that's probably a lot slower.
The idea is basically to not deal with numeric ids anymore but only use
the fully prefixed Q### format. This is because on commons, the
assumption that an identifier consists of a prefix and some digits no
longer applies. Tools and code shouldn't rely on that assumption and
therefore we try to get rid of numeric ids being stored in the database
and use fully prefixed ids instead. Then one can make the assumption
that id and page title are always the same and there is no need for an
Wikidata mailing list