ItemId::newFromNumber and PropertyId::newFromNumber should no longer be used. Production code calling these methods should be changed to use an EntityIdComposer. Test code that uses these methods should be changed to directly call the constructor of ItemId resp PropertyId.
|mediawiki/extensions/Wikibase : master||Fix violations caused by to generic, not needed EntityIdComposers|
|mediawiki/extensions/ArticlePlaceholder : master||Refactor ItemNotabilityFilter to avoid ItemId::newFromNumber|
|mediawiki/extensions/Wikibase : master||Use EntityIdComposer instead EntityId::newFromNumber in client|
|mediawiki/extensions/Wikibase : master||Use EntityIdComposer instead EntityId::newFromNumber in repo|
Change 337045 abandoned by Thiemo Mättig (WMDE):
Use EntityIdComposer instead EntityId::newFromNumber in client
Using the composer only makes sense if either the entity type is variable, or the repo prefix is (or if there is a chance we will make one of it variable in the near future). Neither is the case here. We know the repo prefix is empty. We know the type is "item". Nothing wrong with using the static constructor then. The "wb_items_per_site" table that is used here (via SiteLinkTable) does not support repo prefixes, and as far as I know it does not need to.
I had a look at the remaining usages and they are all fine. All remaining calls of one of these newFromNumber methods are either done on a number as returned by Int32EntityId::getNumericId, which is well specified and encapsulated. Or they are because of T114904: Migrate wb_items_per_site to using prefixed entity IDs instead of numeric IDs, but that has it's own ticket already.