{"id":1453,"date":"2015-08-11T14:54:31","date_gmt":"2015-08-11T13:54:31","guid":{"rendered":"https:\/\/www.entropywins.wtf\/blog\/?p=1453"},"modified":"2022-10-09T23:51:32","modified_gmt":"2022-10-09T22:51:32","slug":"wikibase-datamodel-services","status":"publish","type":"post","link":"https:\/\/www.entropywins.wtf\/blog\/2015\/08\/11\/wikibase-datamodel-services\/","title":{"rendered":"Wikibase DataModel Services"},"content":{"rendered":"

I’m happy to announce the immediate availability of a new Wikibase<\/a> library: Wikibase DataModel Services<\/a> (which I’ll in this blog post refer to as DMS).<\/p>\n

Rationale behind the library<\/strong><\/p>\n

The main motivation for introducing this new library is to reduce technical debt and draw more solid architectural boundaries in the Wikibase code.<\/p>\n

Near the beginning of the Wikibase project we had all our code in the Wikibase.git repository. This could be subdivided into 3 big parts: Wikibase Repository (MediaWiki extension), Wikibase Client (MediaWiki extension) and Wikibase Lib. The latter got introduced to hold code needed by both Wikibase Client and Wikibase Repository. While on the surface that was a reasonable idea, a lot of the things that could go wrong with it unfortunately did. No real boundaries were created in the code, resulting in a tightly coupled blob that even included global state and circular dependencies on Wikibase Client and Wikibase Repository. There also was no contract for what should or can go into Wikibase Lib. Things needed by only one of the MediaWiki extensions were added, on the grounds of them being potentially useful elsewhere, while similar code was left in one of the extensions.<\/p>\n

About a year into the project we realized that things were going in the wrong direction. Even though there was some disagreement on the extent of the problem, the consensus to get rid of Wikibase Lib emerged over time. The first big step there was the extraction of Wikibase DataModel<\/a>, which resulted in the moved-out code improving in quality significantly more than what was left behind. This set the stage for the creation of additional components such as the Wikibase DataModel Serialization<\/a> one that has replaced a chunk of Wikibase Lib code. Unfortunately a lot of the code in Wikibase Lib does not belong to a whole as cohesive as the serialization component. This has led to such code not being moved out, and indeed, has resulted in many new classes being added to Wikibase Lib over time, all but negating extraction work.<\/p>\n

This is not that hard to understand when considering the dilemma faced by people introducing new code needed by both Wikibase Client and Wikibase Repository. Either it needs to go into Wikibase Lib, or a component further down the dependency graph such as Wikibase DataModel. I’ve certainly added several classes to Wikibase DataModel since that seemed to be the best place to put them at the time, polluting this component with DataModel related services that nevertheless are not needed for defining the data model itself. A third place where code inappropriately found its home are the MediaWiki extensions themselves. Code dealing with domain logic or otherwise being application independent is best kept devoid of framework binding.<\/p>\n

All of this taken together suggested the creation of a new library sitting between Wikibase DataModel and the MediaWiki extensions. A library to collect the functionality for which no cohesive component can be created, or for which such creation is not justified. One concern comes up right away: won’t this new general library become a dump ground and ball of mud like Wikibase Lib? To avoid any such fate, we carefully defined the requirements code must satisfy before it is allowed into the component. Such code must…<\/p>\n