Page MenuHomePhabricator

Decide how to handle PropertyId vs FederatedPropertyId in Property-specific services
Closed, ResolvedPublic

Description

We decided in T285453 that it does not make sense for FederatedPropertyId to extend PropertyId. In T286367 we stumbled upon the first service interface that type hints PropertyId (PropertyDataTypeLookup) which does not work with FederatedPropertyId as it is.

We identified the following options for now:

  1. Make FederatedPropertyId extend PropertyId after all
  2. Change all Property-specific service to instead type hint the common parent type, i.e.EntityId
  3. Make PropertyId an interface, rename the "old" PropertyId to LocalPropertyId (?) and make FederatedPropertyId and LocalPropertyId both implement that interface (and also cry because of all the files that would need changing)

Event Timeline

Jakob_WMDE edited subscribers, added: Rosalie_WMDE; removed: rosalieper.

I think we should go with option 3. We briefly talked about this already when we introduced FederatedPropertyId and I think for some reason we had instanceof PropertyId vs ->getEntityType() === 'property' in mind but totally forgot about services that type hint to PropertyId and should keep doing so.

I think the required steps would be

  1. release a new minor WikibaseDataModel version with LocalPropertyId subclassing PropertyId with no modification for forwards compatibility
  2. update the version everywhere to the newly released one and use LocalPropertyId where applicable (any place that instantiates a new PropertyId or uses getNumericId, newFromNumber or newFromRepositoryAndNumber)
  3. release a new major WikibaseDataModel version and make PropertyId an interface, rename the "old" PropertyId to LocalPropertyId
  4. update mediawiki/vendor (possibly also has to happen after step 1?)
  5. make FederatedPropertyId implement PropertyId

I think we should go with option 3. We briefly talked about this already when we introduced FederatedPropertyId and I think for some reason we had instanceof PropertyId vs ->getEntityType() === 'property' in mind but totally forgot about services that type hint to PropertyId and should keep doing so.

I think the required steps would be

  1. release a new minor WikibaseDataModel version with LocalPropertyId subclassing PropertyId with no modification for forwards compatibility
  2. update the version everywhere to the newly released one and use LocalPropertyId where applicable (any place that instantiates a new PropertyId or uses getNumericId, newFromNumber or newFromRepositoryAndNumber)
  3. release a new major WikibaseDataModel version and make PropertyId an interface, rename the "old" PropertyId to LocalPropertyId
  4. update mediawiki/vendor (possibly also has to happen after step 1?)
  5. make FederatedPropertyId implement PropertyId

We decided this approach makes the most sense but since it will introduce major changes, we are going to write an ADR first (see subtask) and implement the solution if/after the ADR is accepted.
In the meantime, to not block our ongoing work, we will make FederatedPropertyId extend PropertyId

Change 704968 had a related patch set uploaded (by Jakob; author: Jakob):

[mediawiki/extensions/Wikibase@master] FP: make FederatedPropertyId extend PropertyId

https://gerrit.wikimedia.org/r/704968

Change 704968 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] FP: make FederatedPropertyId extend PropertyId

https://gerrit.wikimedia.org/r/704968