Re: Possible Future Extensions

Ian McEwen <[email protected]> Mon, 11 May 2015 03:43:58 -0700
Newsgroups gmane.comp.audio.musicbrainz.devel
Message-ID <[email protected]>
--===============1515141022==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="YZ5djTAD1cGYuMQK"
Content-Disposition: inline


--YZ5djTAD1cGYuMQK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, May 11, 2015 at 12:08:32PM +0200, Andre Wiethoff wrote:
> Hello Ian,
>
> >>> One tells the rating is between 1-5, the other between 0-100 (I assume
> >> 0-100 will be used internally?)
> >>
> >> I think I remember reading that they are 0-100 everywhere. I'm sure someone
> >> who knows will say.
> >> I don't know about the rest so I'll leave it for others to answer.
> >>
> > They're 0-100 in the database, but some ways of looking at the data do
> > still return 1-5 values, somewhat confusingly. The /ws/1/rating
> > endpoints seem to do 1-5, where the /ws/2/rating ones do 0-100 (which is
> > perhaps reasonable, since that was a major upgrade). However, adding
> > ?inc=user-ratings in the WS also returns 1-5, and the site interface
> > only allows setting multiples of 20 (i.e. 1-5 stars), though it'll still
> > display the other values.
> >
> > So in principle they're 0-100 everywhere, but in practice there's places
> > that are basically only 1-5 stars. YMMV, etc.
> >
> > We discussed some of the particularities and peculiarities of this in a
> > thread starting at
> > http://lists.musicbrainz.org/pipermail/musicbrainz-devel/2015-February/005933.html
> > (though the start of the thread was for another issue)
> >
> thanks for the information!
>
> I have read through it and I even analysed the tables in a current
> snapshot of the Musicbrainz DB.
> I found the following:
>
> All tables called "_rating_raw" are empty!
> But on the other hand, the "_meta" tables does contain information!!
>
> artist_meta: 25215 ratings
> recording_meta: 219029 ratings
> work_meta: 1419 ratings
> label_meta: 602 ratings
> release_group_meta: 65150 ratings
>
> Most probably the "_rating_raw" tables are aggregated and then deleted
> afterwards?
> I assume that the exact editor/rating values are lost forever? This
> would really a pity to loose so many recording rating information
> (groupable to editors/users)...
>
> Would it be possible to not delete the rating information in the future?
>

The _rating_raw tables are the raw ratings, and they correspond to the
private data of exactly which users submitted exactly which ratings. The
_meta tables have the aggregate ratings.

In the real database the _rating_raw tables aren't empty, but the
downloadable snapshots don't include data for those tables, since by
default the exact pairings are private, at the discretion of the editor
in question. So none of that information is absent in the actual
database, it's just not released publicly.

Similarly, collections (even public ones), tags (other than aggregated
ones) and subscriptions aren't in public dumps.

There's a ticket for releasing files that contain collections,
unaggregated tags and ratings, and subscriptions for editors who have
indicated in their user preferences that they can be made public:
http://tickets.musicbrainz.org/browse/MBS-7560 -- it hasn't seen much
progress yet though. Always too much to do :)

> Best regards,
>
> Andre
>
> (just as a sidenote: and what I also found was that the "_meta" tables a
> contain additionally a lot of rows, which only references the object,
> but have no values for "rating" and "rating_count"... E.g. the
> "recording_meta" table has in total 14.791.695 entries, of which
> 14.608.329 actually doesn't contain a rating - it seems that every
> recording has an entry in recording meta automatically...)
>

Yes, these rows are created automatically. While for the recording table
this table only contains rating information, for other things (releases
and release groups) it contains other information that's much less
rarely empty/missing, so it's much easier to just create these rows
automatically with a trigger so that we can count on the rows always
existing, so we don't have to deal with upserts, outer joins, etc.

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

--YZ5djTAD1cGYuMQK
Content-Type: application/pgp-signature

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

iEYEABECAAYFAlVQh+wACgkQq+0avXExp2/f2QCgxM2eZSRF9Dk5lU5JdWNrzjBV
bUEAn2BcpTeXoeQkcz9sWqUVnE5yl6Sd
=NThu
-----END PGP SIGNATURE-----

--YZ5djTAD1cGYuMQK--


--===============1515141022==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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