Indeededy.
I think this will be good enough for a first stab and to get us moving.
The main place I'm worried about race conditions is speed unwatching /
speed adding articles. Storing in separate sub pages won't help with this.
I think this is a huge flaw in this approach and I imagine at some point
we will have to switch over to a database but right now I think it's more
important to get something in front of people. In short I imagine we won't
be using user pages by the end of the quarter.
On Wed, Feb 4, 2015 at 9:36 AM, Sam Smith <samsmith(a)wikimedia.org> wrote:
I've left some comments on PS8.
The race condition is a result of the way the data is structured and
stored: the entire collection and its metadata is stored in one wiki page
as a JSON blob, which can't be updated without reading and writing the
complete manifest.
In the example you've provided, you create and manipulate two new
collections simultaneously. If the requests are processed at roughly the
same time, then both fail to load the user's collections, create a new one
and attempt to write a manifest with a single collection in it. Both API
requests will succeed but only one collection will exist. Only if there's a
significant delay – longer than it takes to process a single request, say –
in the processing of one of the requests, *or the requests are ordered*,
then the first request will successfully create a manifest with a single
collection in it and then the second request will add a new collection to
the manifest.
An alternative implementation, which AFAICT you've already considered, is
to use sub-pages to store collections, e.g.
User:Phuedx/Collections/Favourite_Post-metal_Albums, where the
User:Phuedx/Collections page acts as a manifest but you never explicitly
update it. Don't worry about auto-incrementing IDs, just map the name of
the collection to the title of the sub-page. A nice consequence of this is
that the URLs are human-readable. Better still, the Title class can do
all of the heavy lifting (see Title::makeTitleSafe and Title#getSubPages
).
Note that you may still see race conditions at the collection level, if,
say, the user is editing the collection of their favourite post-metal
albums* in multiple windows or tabs or across multiple devices.
–Sam
* Got any suggestions?
On Tue, Feb 3, 2015 at 9:26 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
I explored using User pages as a storage
mechanism for the minimal
viable product for the collections work the mobile team is doing. The
goal is to prove the success of the feature and then feed our findings
into the multiple lists in core RFC.
I completed a proof of concept patch for storing collections as lists.
Essentially it stores all the meta data associated with a users
collection as a page at User:<username>/MobileWebCollections.json
You can test it out by:
1) checking out:
https://gerrit.wikimedia.org/r/#/c/188225/
2) visiting Special:MobileCollections
3) refreshing page and seeing a collection with 2 items in it
Whilst doing this I have discovered that potentially race conditions
could be an issue with this approach. The sample code carries out
various transactions and the end state can differ based on which
finish first. I'm not much of a PHP expert so I'm not sure how to
remedy this problem. It may not be a problem based on the fact that we
only anticipate one user managing these lists at a given time.
Apart from the race condition it seems to work nicely. I imagine the
API could also be used to handle watchlist watch and unwatch actions
so that we wouldn't have nasty special cased code for watching
articles.
Currently the API is only designed to work on private lists for the
current user. I would expect a user parameter to be added later.
Let me know if you have any questions.
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
* @rakugojon
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org