| Lucas_Werkmeister_WMDE added a subscriber: Ladsgroup. Lucas_Werkmeister_WMDE added a comment. |
what do we do?
So here are the things that you need in order to check constraints on a Context:
- type (e. g. “used as qualifier” constraints)
- snak (e. g. “one of” constraints)
- snak rank (many constraint types are disabled on deprecated statements – although that is the only use of getSnakRank(), and we might want to turn that into a declarative solution instead, similar to the supported context types)
- entity ID (e. g. “symmetric”, “inverse” constraints)
- entity statements (e. g. “item requires statement” constraints)
- snak group (e. g. “single value” constraints)
And here are the things that you need in order to store a CheckResult into the right place according to its Context:
- type
- entity ID serialization
- statement property ID serialization
- statement GUID
- snak hash
- snak property ID serialization (qualifier, reference only)
- reference hash (reference only)
The two sets are almost completely disjoint, though the second one can be mostly derived from the first one. So perhaps we should split them up? The checkers get the first set of data in something called, dunno, a ContextData container. A CheckResult contains the second set of data in, uh, a ContextCursor. And we only need to deserialize ContextCursors (which, you’ll observe, exclusively consist of strings), not ContextData. The separation between the two isn’t entirely clean because the checkers need some way to get a ContextCursor from the ContextData (so that they can instantiate a CheckResult – unless the cursor is only attached at the DelegatingConstraintChecker level? hmm), but since a ContextCursor can be mostly derived from ContextData (except that ContextData doesn’t explicitly contain the statement), that shouldn’t be a huge problem.
@Ladsgroup since IIRC you were unhappy with the old Context interface… any thoughts on this? (I’m afraid it’s still more than one method per interface, though.)
On the other hand – that separation is a lot more work than I assumed for this task, so I admit I’m tempted to go with the much simpler
Return some fake EntityDocument that only holds the ID and nothing else
at least temporarily… in fact such a FakeEntityDocument implementation already exists (though only in the tests of data-model-services).
Cc: Ladsgroup, Aklapper, Lucas_Werkmeister_WMDE, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Agabi10, abian, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
