jayvdb added a comment.
In https://phabricator.wikimedia.org/T115679#1968762, @thiemowmde wrote:
> Have a look into the file ApiQuerySiteinfo.php and how it works. It's
> impossible to inject something like `meta=wikibase`. Why do you call this
> "deprecated"? This never existed, as far as I
thiemowmde added a comment.
Sorry, I got confused. I fixed my comment above. So what you are proposing is a
new ApiRepoInfo? Sure, "somebody" could do that, as said above.
TASK DETAIL
https://phabricator.wikimedia.org/T115679
EMAIL PREFERENCES
thiemowmde added a comment.
Have a look into the file ApiQuerySiteinfo.php and how it works. It's
impossible to inject something like `meta=wikibase`. Why do you call this
"deprecated"? This never existed, as far as I can see.
What we currently have in https://gerrit.wikimedia.org/r/247080 is
daniel added a subscriber: daniel.
daniel added a comment.
Does pywikibot differentiate between value type and data type? Does pywikibot
even *use* the data type as such? The value type is not going to change, only
the data type.
For example, for the "url" data type, the value type is
jayvdb added a comment.
Pywikibot does use the data type, quite extensively. e.g.
https://github.com/wikimedia/pywikibot-core/blob/master/pywikibot/page.py#L3951
They are mapped to classes, and mapped to value-types.
With something like https://gerrit.wikimedia.org/r/247080 , we can easily
Legoktm added a comment.
In https://phabricator.wikimedia.org/T115679#1732494, @jayvdb wrote:
> What would be nice is if Wikibase provided an API call to list all datatypes,
> so we can detect when the list of datatypes changes. i.e. expose
>
hoo added a comment.
I'm not sure what's the best to do for pywikibot here, but the plan is to
perform such a change only **once**, on a previously discussed (thus known in
advance) list of properties. Because of that, I think having a one-off solution
would be ok here.
If there's anything
XZise added a subscriber: XZise.
XZise added a comment.
By the way the cache time doesn't matter that much as the cached item does not
store the time of expiration but the time of creation. So we could reduce the
time and anyone who uses a version after that won't have cached it for about
100
Lydia_Pintscher added a comment.
I would recommend lowering the caching. We really try to not change the
datatype of a property but I can't promise this will be the only time.
TASK DETAIL
https://phabricator.wikimedia.org/T115679
EMAIL PREFERENCES
Ricordisamoa added a subscriber: Ricordisamoa.
Ricordisamoa added a comment.
https://gerrit.wikimedia.org/r/137737 and https://gerrit.wikimedia.org/r/227252
basically mean that `getPropertyType` only gets called when `Property` is
constructed manually, right?
TASK DETAIL
jayvdb added a comment.
In https://phabricator.wikimedia.org/T115679#1732247, @Ricordisamoa wrote:
> https://gerrit.wikimedia.org/r/137737 and
> https://gerrit.wikimedia.org/r/227252 basically mean that `getPropertyType`
> only gets called when `Property` is constructed manually, right?
Yes.
Legoktm added a comment.
Do we expect this to happen again? A property's datatype is supposed to be
immutable, and except for this one weird case, it is. Unless we can also vary
on some other constant changing, I don't see any good cache invalidation
strategy here.
If we expect this kind of
12 matches
Mail list logo