Page MenuHomePhabricator

Move services in DataModel to DataModel Services
Closed, ResolvedPublic

Description

This is to collect and track services to move from Wikibase DataModel to Wikibase DataModel Services as per https://phabricator.wikimedia.org/T93741

  • ByPropertyIdGrouper
  • LegacyIdInterpreter
  • PropertyIdProvider (not entirely sure about this one)
  • Entity / EntityIdParser + derivatives
  • Entity / EntityIdParsingException
  • Entity / PropertyDataTypeLookup
  • Entity / InMemoryDataTypeLookup
  • Entity / PropertyLookup
  • Entity / PropertyNotFoundException
  • Entity / ItemLookup
  • Entity / ItemNotFoundException
  • Statements / BestStatementsFinder
  • Statements / StatementGuidParser
  • Statements / StatementGuidParsingException
  • All the diffing and patching code

Event Timeline

JeroenDeDauw raised the priority of this task from to Needs Triage.
JeroenDeDauw updated the task description. (Show Details)
JeroenDeDauw added a subscriber: JeroenDeDauw.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 29 2015, 11:31 AM
This comment was removed by JeroenDeDauw.
thiemowmde added a comment.EditedJun 29 2015, 12:04 PM
  • Parsers and lookups and such are obviously much closer to "services" than they are to a "model".
  • ByPropertyIdGrouper: I always found this class weird. It could even be rewritten to pass id serialization strings instead of EntityId objects. With this simple change the class would be completely independent from everything. It would have literally no dependencies. So yes, please move or even remove.
  • LegacyIdInterpreter is closely bound to the two base entity types. It's an other way to call the Item and Property constructors. One could argue that this classifies as a "service". I think it should stay in DataModel or be removed completely.
  • PropertyIdProvider: Not a service. Useful when you do not want to bind against Wikibase-DataModel-Services. So Wikibase-DataModel please.
  • StatementGuidParser: I do not like the idea of having the code that constructs these GUIDs in one component and the code that can parse ("deconstruct") them in an other. This means the knowledge about the internal structure of these GUIDs is split (and possibly duplicated) across two components.

On StatementGuidParser: Right now we have the GuidParser in DataModel and the GuidGenerator in Wikibase Lib. The idea is to move both to DataModel services. Does that not improve the situation? Am I forgetting about something else? I'm not sure what is being referred to by "deconstruct".

Bene added a comment.Jun 29 2015, 6:13 PM
  • No to PropertyIdProvider, it's a useful interface and should remain in Wikibase DataModel. Otherwise, classes cannot implement it.
  • Agree with @thiemowmde on the LegacyIdInterpreter
  • ByPropertyIdGrouper should go into DataModel Services. I don't think it should be rewritten but that's another discussion. ;-)
  • Yes, move all the StatementGuidParser and the GuidGenerator both into the Services\Statement namespace.

GuidParser in DataModel and the GuidGenerator in Wikibase Lib. The idea is to move both to DataModel services.

That's cool, thanks for pointing this out.

"deconstruct".

Means "parse".

JeroenDeDauw updated the task description. (Show Details)Jul 1 2015, 6:30 PM
JeroenDeDauw set Security to None.

I've updated the list. Let's move on with moving the stuff :)

Addshore closed this task as Resolved.Jul 24 2015, 5:42 PM
Addshore claimed this task.

These classes and interfaces have been added to the new component and I submitted a PR with the removal of the old copies at https://github.com/wmde/WikibaseDataModel/pull/516

This comment was removed by JeroenDeDauw.