A quick heads up:
I'm about to remove the LBFactory_Multi (or rather: disabling) setup in
WikibaseClient.example.php:
https://gerrit.wikimedia.org/r/#/c/70164/3
This setup allows the client to communicate with a repo database on a different
database server. However, this interferes with testing, especially with testing
environments using sqlite, as jenkins does.
Note that the example never worked out of the box: the example settings are
designed for two ports and multipe IPs on the local host to be configured for
MySQL, while MySQL per default only listens on a unix socket. It either needs to
be adapted to the user's actual MySQL setup, or requires the user's MySQL
install to be changed.
Since the setup for LBFactory_Multi is not obvious, an example is useful, but I
made it inactive per default.
If you have been using it, copy the disabled example into your own LocalSettings.php
-- daniel
Tomorrow at 2pm Berlin time, the Wikidata team will host a public hangout
on Travis. This is mostly meant to inform ourselves, but it might be a good
resource for others as well.
We might be late, as this is the first time we are doing such a thing, so
bring a bit patience.
We will try to record it and make it available afterwards.
We will send the login data and URLs to IRC on #wikimedia-wikidata around
that time.
Thanks to Jeroen for preparing the session, and Lydia for the technical
setup.
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi all,
as we just decided, because it is too hot, we will skip deployment cycle
wmf-8 too.
We will have a code freeze on Tuesday, 25th, at 4pm, to orderly prepare for
the following deployment (i.e. wmf-9).
For the future, we are currently discussing internally how to make this a
bit smoother.
Cheers,
Denny
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hey,
Since we now have a few more components, here are some new handy shortlinks:
* Review queue: http://bit.ly/wdrieview
* Merged stuff: http://bit.ly/wdmrgd
Included new repos are: WikibaseDataModel, WikibaseDatabase, WikibaseQuery,
WikibaseQueryEngine
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
Hi all.
Currently, a PropertyValueSnak knows the ID of the property it refers to, and
the DataValue object representing the actual value. The DataValue has a "low
level type" used (in the future) by the storage and indexing layer. But whenever
we want to render or validate a snak, we need the property's high level data type.
Currently, we do this via the PropertyDataTypeLookup service.
I think that's quite inconvenient and inefficient. I think the Snak itself
should know the data type's ID. Was there any particular reason not to do this?
I remember a lengthy discussion about this, but I don't recall the outcome (yes,
we really need to write this stuff down).
Having the data type in the Snak would mean that Snaks are self-contained in the
JSON structure, and it would also make us robust against a property changing
it's type.
Of course, changing this now means we have to provide some kind of fallback for
the case that the type id is missing - and that is going to require a
PropertyDataTypeLookup again. Annoying :/
Alternatively, Snak objects could require the type in the constructor - but that
would require database lookups during deserialization; not fun.
Any thoughts on this? Why did we go this route? And is it really too late to
change this now?
-- daniel
Hey,
The PHPUnit tests for Wikibase Repo and Wikibase Client are now run on
TravisCI! There where the last two of our components on the TODO list, so
we now have all our PHPUnit tests running there.
Right now Travis is running 6 jobs for every commit: half repo, half
client. half mysql, half sqlite. And 2 for each of PHP 5.3, 5.4 and 5.5.
https://travis-ci.org/wikimedia/mediawiki-extensions-Wikibase/builds/8155338
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil. ~=[,,_,,]:3
--
A quick heads up:
We have a breaking change for the API in the pipeline:
<https://gerrit.wikimedia.org/r/#/c/68406/12>. This has not been merged yet, but
I expect this to go into the next branch (to be deployed on June 24, if I'm not
mistaking).
It's really a fix for previously underspecified and dangerous behavior:
the editentity module would automatically create a new item when called without
giving an ID of the entity to modify.
With the patch, editentity now requires that either the 'id' parameter or the
'new' parameter be set, explicitly stating which entity to modify resp. what
kind of entity to create.
That is, bots that wish to create an item now need to provide the new=item
parameter, instead of just not supplying an id parameter. This affects all bots
that create items.
We could keep the old behavior as a B/C mode, but it's dangerous and ill
defined; I think it's better to break some bots now, it's easy to fix anyway.
But it should of course be announced in due time.
-- daniel
I' currently thinking about how to best validate incoming Snaks / DataValues.
I have been looking at the ValueValidator interface, and it seems to be somewhat
inconvenient.
* why do we need the setOptions() method? Shouldn't the validator be fully
configured in the constructor?
* why is there no canValidate() method? This would be very handy for finding
applicable validators for a given object.
This seems a bit odd, but where it gets really problematic is the
ValueValidatorsObject base class:
* why are errors collected in a member? I would expect a validator to be
stateless and reusable.
* why do we need the Result object? Can't we just throw an exception? The "value
with warnings" use case for MediaWiki's status object doesn't seem to apply here.
* There is a lot of "convenient stuff" implemented in the base class which i
expect many implementations are not going to need, e.g. the
allowdValues/forbiddenValues stuff.
* options are passed to sub-validators using an option map, changing the
configuration and thus behavior of the (sub-)validators on the fly. That seems
like asking for trouble.
I propose a lighter design:
* the ValueValidator interface has two methods, validate() and canValidate().
validate() can throw a validation exception, which contains one or more errors.
* Validators are stateless and get configured completely and finally by the
constructor.
* Validators should generally implement only a single constraint - so instead of
a String validator that implements min/max length, min/max value, and a regex
check, each of these checks should have their own validator; A
CompositeValidator could be used to bundle multiple validations, if needed.
* ValueValidatorFactory gets a getApplicableValidators() method that returns all
validators that can be used to validate a given object.
As far as I can see, the Validator interface isn't yet widely used, so it would
be easy enough to change these things.
What do you think?
-- daniel