Page MenuHomePhabricator

[EPIC] wbformatentities with both local and remote properties
Closed, ResolvedPublic13 Estimated Story Points

Description

As a user who already has a Wikibase containing properties, when I enable federated properties I want to see responses from both my local and the remote repository at the same time in the wbformatentities API.

This would mean with one local and one remote entity ID as an input to wbformatentities, the response would contain entity data from each of these entities.

We would limit this to only using standard content languages.

BDD
Scenario: Federated Property
Given I have enabled federated properties in a Wikibase containing local properties
When I call wbformatentities with a federated property entity ID
Then I see the link to the federated property with a label

Scenario: Local Property
Given I have enabled federated properties in a Wikibase containing local properties
When I call wbformatentities with a local entity ID
Then I see the link to the local property with a label

Scenario: Local & Federated Property
Given I have enabled federated properties in a Wikibase containing local properties
When I call wbgetentities with a local entity ID AND a federated entity ID
Then I see links to both the local and the federated property with a label

Related Objects

Event Timeline

Jakob_WMDE renamed this task from wbgetentities with both local and remote properties to wbformatentities with both local and remote properties.Jun 23 2021, 10:08 AM
Jakob_WMDE updated the task description. (Show Details)

Notes from task breakdown:

  • create a new class for these federated property ids that extends EntityId
  • create a FederatedPropertyAwareDispatchingEntityIdParser (or find a snappier name!) that wraps DispatchingEntityIdParser and creates new federated property ids from serialization or delegates to DispatchingEntityIdParser if the serialization is not a URI. The new parser can either directly create the new id objects or use a builder callback.
  • use FederatedPropertyAwareDispatchingEntityIdParser instead of DispatchingEntityIdParser if federated properties is enabled
  • FederatedPropertyAwareDispatchingEntityIdParser validates the concept URI and checks whether there is an entity source defined for that concept URI
  • all properties (federated or local) currently use LabelsProviderEntityIdHtmlLinkFormatter which depends on lots of services (EntityExistenceChecker, EntityTitleTextLookup, ...) that are swapped out by the entity type definitions when federated properties is enabled.

Dispatching by entity id and entity source

  • at the moment one entity type uniquely identifies an entity source. we're going to break that assumption!!! \o/
  • consequently we can no longer dispatch by entity type alone to get a service that does what it's supposed to do
  • therefore we should consider if the existing dispatching code should stay with an additional dimension (the entity source) or if we should build a new type of dispatching
  • consider replacing all uses of instanceof PropertyId with getType() === 'property'
  • consider investigating if old style federation entity id prefixes are used anywhere. are they flying around in the commons database?

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

[mediawiki/extensions/Wikibase@master] WIP: introduce dispatching by source and type

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

Change 701135 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] FP: Make TypeDispatchingExistenceChecker Type and Source Dispatching

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

Services that need to become type and source dispatching aware:

  • 'WikibaseRepo.EntityIdHtmlLinkFormatterFactory'
    • Either 'WikibaseRepo.EntityTitleLookup'
    • Or 'WikibaseRepo.EntityTitleStoreLookup'
Samantha_Alipio_WMDE renamed this task from wbformatentities with both local and remote properties to [EPIC] wbformatentities with both local and remote properties.Jul 7 2021, 9:08 AM