User Details
- User Since
- Oct 20 2014, 11:38 AM (496 w, 4 d)
- Availability
- Available
- LDAP User
- Jakob
- MediaWiki User
- Jakob Warkotsch (WMDE) [ Global Accounts ]
Thu, Apr 25
Wed, Apr 24
Tue, Apr 23
Mon, Apr 22
Here are the corresponding action API responses for four of the cases:
I think this should probably be prioritized higher. After a software update, my mwcli broke pretty spectacularly similar to the error described here and here. For now I managed to fix the problem by uninstalling docker-compose, installing the docker-compose-plugin and aliasing docker compose to docker-compose. I now get a bunch of warnings saying .config/mwcli/mwdd/default/[service].yml: version is obsolete but at least it's working again.
I tested this with a simple e2e test that does the following: 1. create item, 2. create property with data type item, 3. create statement on item using the newly created property, 4. get the new statement. This all worked fine out of the box, so I added an artificial delay to the DataUpdater that inserts the property info which is needed for the data type lookup. Interestingly the statement creation never failed, because it uses the data type lookup that has a fallback on top of the property info based lookup. In step 4 the statement value shows the UnDeserializableValue serialization while the data type lookup fails.
Fri, Apr 19
Thu, Apr 18
Wed, Apr 17
Tue, Apr 16
Thanks for spotting this issue! We had wbformatvalue on our radar as well. Getting it to work as long as datatype or property are provided should be straightforward. I'll make a patch!
Thu, Apr 11
Wed, Apr 10
Fri, Apr 5
Thu, Apr 4
Wed, Apr 3
If I'm not mistaken there is already a field in DataTypeDefinitions for exactly this purpose called parser-factory-callback. From the docs: "ValueParser for this data type" which is what we want. Looking through the code, this field so far was effectively only used for *value* type definitions. A few extensions do use it (codesearch) for data type definitions, but most (all of the ones active on wikidata) only copied the default code for the corresponding value type, which doesn't have any effect.
Tue, Apr 2
@Ifrahkhanyaree_WMDE I don't think this should apply to PATCH entities/properties/property_id. Any modification of a statement ID, or an attempted creation of a statement with an ID should result in a statement-id-not-modifiable error when patching a property IMO.
Mar 19 2024
Yes, thanks!
Mar 15 2024
Mar 14 2024
Mar 13 2024
Product-verifiable on beta: https://wikidata.beta.wmflabs.org/w/rest.php/wikibase/v0/property-data-types
Mar 12 2024
Mar 11 2024
Mar 7 2024
Mar 6 2024
Mar 5 2024
I don't think this needs to be a train blocker. We just agreed in a meeting with our PM (cc @Ifrahkhanyaree_WMDE) that we're fine with it being broken for a week given this is all still considered experimental. Patch requests using application/json as the content type still work, only application/json-patch+json doesn't.