Re: Ratings and throttling

On Mon, Feb 16, 2015 at 08:34:01PM -0800, Joe Martinez wrote:
> >
> > The only thing I can think of offhand is that you can get recording
> > ratings via release requests and via recording browse requests, e.g. by
> > artist. So if you have release tags and artist tags you may be able to
> > get ratings for all recordings at once (or, in the case of browse
> > requests, up to 100 at once via the limit parameter).
> >
>
> If I did it by release, then I'd need to do a separate query for each
> release, right?  I guess that would be faster than one request per
> recording, but if I have 600 albums, then that would take about 10
> minutes.  Still a bit slow.  And, if a release had more than 25 recordings,
> then it would get truncated.
>

I believe these would not be truncated, since it's not a listing of
pages, it's listed in the context of the tracks. So I believe you'd get
the whole release's worth of recordings. There's also browsing
recordings by release, of course, which would certainly make everything
available, if possibly by multiple pages.

Other concerns definitely still apply. Just figured I'd mention this,
since it could at least be somewhat fewer requests (in an ideal case,
100fold reduction).

> Doing a browse request by artist I think would have a similar problem.  If
> I have 300 artists, that's 300 requests, each of which may have several
> 100-recording pages, so that might take just as long.
>
> And since in both of these cases, I'm getting back lots of data that I
> don't care about (recordings that I don't own), it's probably not too nice
> to the server.
>

Certainly. The release one I figured was possibly more straightforward,
since it's a frequent case that someone has whole releases. Whole-artist
requests would probably not be except in very exceptional cases.

> Thanks for the info and ideas, though.  I really hope somebody implements
> the feature request that Ulrich linked to.  It would make eveything nice
> and clean.  It doesn't sound like too difficult a job.  I'd possibly
> volunteer myself if I knew Python :)
>

Perl, in point of fact, not Python :) but I suspect that's no better for
your case.

Incidentally, I notice that it's undocumented, but looking at the code,
a more bandwidth-intensive rating lookup does exist at
/ws/2/rating?entity=<type>&id=<mbid> -- perhaps that could be relatively
rapidly extended to support what's desired here. (I notice it returns
nothing when there's no rating, just <metadata/>, and 1-100 values when
there is one, in the light of previous observations of inconsistency).

Alternatively to the way that ticket presents it, perhaps allowing
something like browse requests would be more reasonable --
/ws/2/recording?rating_editor=whoever&limit=100 or so (and, presumably,
tag_editor or such). That'd keep it more consistent with the typical
case where recording (or whatever else) information is also desired.

> So, it looks like I might have to resort to using the user rating web page
> and scraping the HTML (as the feature request mentions), and just hope that
> the format doesn't change :(
>
> -Joe

> _______________________________________________
> MusicBrainz-devel mailing list
> [email protected]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

_______________________________________________
MusicBrainz-devel mailing list
[email protected]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlTi8Q8ACgkQq+0avXExp2+2xACfVb40TGPBr9m4K7bmM4DKA9Qj
SbQAnj65yTs5JvZMclRr7p4GqoqOgBJ9
=w3My
-----END PGP SIGNATURE-----