Looks good for getting started.
A potential way of avoiding races (by blatantly failing) would be requiring a revision or last modified date for the collection being edited, and comparing it with the current version when trying to save. If they don't match, return an error so that the user has to update the collection view before editing it.
Still probably too complex and as you guys way won't be necessary when we switch to db.
On Wed, Feb 4, 2015 at 4:14 PM, Jon Robson jdlrobson@gmail.com wrote:
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@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@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:
- checking out: https://gerrit.wikimedia.org/r/#/c/188225/
- visiting Special:MobileCollections
- 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Jon Robson
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l