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 <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/mobile-l >> > > -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon
_______________________________________________ Mobile-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mobile-l
