[mb-devel] Problems with musicbrainz service (502 errors)

[Frederic Da Vitoria]

2011/12/6, Oliver Charles <oliver.g.charles.work at gmail.com>:
> Frederic Da Vitoria <davitofrg at gmail.com> writes:
>> Thanks, it is getting clearer. I guess I drew conclusions too quickly
>> from "recording id" in which "recording" is to be taken in the
>> database sense, not in the audio sense. But under the first <relation
>> type="performance"> I find other <relation type="performance">. Isn't
>> this where the system is going (at least semantically) backwards?
>
> Yuck, what a horrible concept. Relationships are *unordered* links
> between 2 entities. The whole 'forward' or 'backward' notation simply
> means if the entity types are alphabetical or not (artist-work vs
> work-artist).
>
>> BTW, the secondary performances are flagged as "backward". So, if you
>> don't manage to make response times shorter, wouldn't this be a good
>> point to prune the results: don't include "backward" results?
>
> As I said above, there's no clear definition of direction other than
> something fairly arbitrary. If it means "by which direction you found a
> relationship" then work-recording relationships should be *forward* --
> you moved from Release -> Recording -> Work -> Recording.

I obviously was not clear enough. what I meant is that in your chain
above "Release -> Recording -> Work -> Recording", if the same item
appears twice, I feel you are doing something larger that what I would
really expect. What I meant is that the results go from Release to
Recording to Work then *back* to Recordings. Sorry, "backwards" was
not the correct word, it was misleading.

But avoiding a type of information which the query already went
through may not be easy. And the benefits are not obvious: maybe the
volume of results wouldn't change much, and maybe the query would
actually be slower.

-- 
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org