#musicbrainz

/

      • luks
        ah, I don't know, do we want to copy anything?
      • 2009-04-16 10634, 2009

      • luks
        I'm biased, since I wrote that, so I can't answer objectively :)
      • 2009-04-16 10635, 2009

      • ruaok
        well, hopefully we won't throw our everything...
      • 2009-04-16 10646, 2009

      • aCiD2
        biased yes, but you know best in this area :)
      • 2009-04-16 10658, 2009

      • aCiD2
        as in what do you think works well and what you'd want to rewrite
      • 2009-04-16 10635, 2009

      • ruaok
        its clear the aritst and release pages will need to be nearly completely redone.
      • 2009-04-16 10636, 2009

      • luks
        well, we definitely need a different layout for the release page
      • 2009-04-16 10658, 2009

      • luks
        the artist page is actually ok as it is, once we get release groups
      • 2009-04-16 10621, 2009

      • aCiD2
        the artist header doesn't work well with credits though
      • 2009-04-16 10643, 2009

      • luks
        yes, we need to get rid of that
      • 2009-04-16 10625, 2009

      • ruaok
        slightly OT... are you waiting for the start of SoC to start hacking on NGS?
      • 2009-04-16 10611, 2009

      • luks
        MBChatLogger: off
      • 2009-04-16 10611, 2009

      • MBChatLogger
        is not logging
      • 2009-04-16 10632, 2009

      • MBChatLogger
        is logging
      • 2009-04-16 10634, 2009

      • ruaok
        hi murdos!
      • 2009-04-16 10642, 2009

      • murdos
        hey
      • 2009-04-16 10644, 2009

      • pronik
        but at least it has been clear to me that I need to learn a lot more to qualify
      • 2009-04-16 10659, 2009

      • ruaok checks out release groups
      • 2009-04-16 10655, 2009

      • aCiD2` joined the channel
      • 2009-04-16 10617, 2009

      • aCiD2 has quit
      • 2009-04-16 10618, 2009

      • ruaok
        hey luks: For the ISRC table, mimicking PUID, do you see a reason why we need a join table like puid_join?
      • 2009-04-16 10626, 2009

      • Munger
        If an Amzon listing has all the right tracks but in the wrong order, do I count that as the correct ASIN? I suspect an Amazon data entry monkey has got their track listing muddled
      • 2009-04-16 10645, 2009

      • ruaok
        I get the impression that | id, FK to track, ISRC | is all we need.
      • 2009-04-16 10635, 2009

      • luks
        if we don't need any oother metadata abgout the isrc, then one table should be enough
      • 2009-04-16 10649, 2009

      • ruaok
        I can't think of anything.
      • 2009-04-16 10656, 2009

      • ruaok
        lookup is not too relevant.
      • 2009-04-16 10603, 2009

      • ruaok
        client version doesn't apply.
      • 2009-04-16 10604, 2009

      • luks
        we might want to track the origin of the isrc, maybe
      • 2009-04-16 10620, 2009

      • luks
        as most of them are probably going to be submitted automatically
      • 2009-04-16 10626, 2009

      • ruaok
        but thats just anohter column on table ISRC, right?
      • 2009-04-16 10655, 2009

      • luks
        hm, yes, that would actually work better than in a spearate table
      • 2009-04-16 10612, 2009

      • ruaok
        source? origin?
      • 2009-04-16 10659, 2009

      • murdos
        [22:56] <ruaok> lookup is not too relevant. <= do you mean lookup by ISRC?
      • 2009-04-16 10617, 2009

      • ruaok
        murdos: counting how many times an ISRC has been looked up.
      • 2009-04-16 10629, 2009

      • ruaok
        lookup by ISRC is obviously important. :)
      • 2009-04-16 10631, 2009

      • murdos
        oh... right
      • 2009-04-16 10641, 2009

      • murdos
        sure :)
      • 2009-04-16 10613, 2009

      • ruaok
      • 2009-04-16 10615, 2009

      • ruaok
        thoughts?
      • 2009-04-16 10640, 2009

      • luks
        modpending?
      • 2009-04-16 10600, 2009

      • ruaok
        oh yeah.
      • 2009-04-16 10612, 2009

      • ruaok
        man, we need to pull all those out into a separate table.
      • 2009-04-16 10617, 2009

      • luks
        and ISRC is not CHAR(36) :)
      • 2009-04-16 10622, 2009

      • ruaok
        another thign for post NGS.
      • 2009-04-16 10632, 2009

      • ruaok
        oops. do you know what it is?
      • 2009-04-16 10642, 2009

      • luks
        not sure
      • 2009-04-16 10648, 2009

      • luks
        ah, 12 characters
      • 2009-04-16 10651, 2009

      • Muz
        12 charaters.
      • 2009-04-16 10652, 2009

      • luks
        according to wikipedia
      • 2009-04-16 10652, 2009

      • Muz
        Bleh.
      • 2009-04-16 10628, 2009

      • chefkoch_ joined the channel
      • 2009-04-16 10638, 2009

      • chefkoch has quit
      • 2009-04-16 10639, 2009

      • chefkoch_
        chefkoch_ is now known as chefkoch
      • 2009-04-16 10645, 2009

      • luks
        hmm, we even might want to track the parts of an ISRC separately
      • 2009-04-16 10607, 2009

      • ruaok
        like country?
      • 2009-04-16 10622, 2009

      • luks
        yes, or registrant
      • 2009-04-16 10646, 2009

      • luks
        I don't know yet what for, but it seems it could be useful for somebody some day
      • 2009-04-16 10653, 2009

      • Muz
        It's country, registrant, year, and numeric id iirc.
      • 2009-04-16 10614, 2009

      • Muz
        Those being 2, 3, 2, 5 chars in length.
      • 2009-04-16 10616, 2009

      • ruaok
        I'd be inclined to add some meta index table then, rather than now.
      • 2009-04-16 10623, 2009

      • luks
        ok
      • 2009-04-16 10639, 2009

      • czaanja joined the channel
      • 2009-04-16 10650, 2009

      • pronik
        aCiD2`: we badly need tests :(
      • 2009-04-16 10658, 2009

      • pronik
        see github code review
      • 2009-04-16 10601, 2009

      • luks
        write some
      • 2009-04-16 10602, 2009

      • aCiD2`
        what bought that up :)
      • 2009-04-16 10616, 2009

      • aCiD2`
        luks: what's the point if ngs is just gonna rip the whole current object model out
      • 2009-04-16 10636, 2009

      • aCiD2`
        pronik: = is valid
      • 2009-04-16 10644, 2009

      • luks
        I don't know, but if pronik wants tests :)
      • 2009-04-16 10648, 2009

      • aCiD2`
        :)
      • 2009-04-16 10657, 2009

      • pronik
        aCiD2`: sure?
      • 2009-04-16 10602, 2009

      • aCiD2`
        pretty certain
      • 2009-04-16 10618, 2009

      • pronik
        are those up on test?
      • 2009-04-16 10625, 2009

      • aCiD2`
        yup, sohuld be
      • 2009-04-16 10659, 2009

      • aCiD2`
        pronik: how about now, I'll add stricter TT checks, and write Test::WWW::Mechanize tests that do a get request on all pages, and ensure at least that they return sucessful
      • 2009-04-16 10645, 2009

      • pronik
        you could, but I'd prefer something with workflow along the way, selenium for example
      • 2009-04-16 10656, 2009

      • pronik
        test::more with selenium should suffice for the start
      • 2009-04-16 10658, 2009

      • aCiD2`
        When catalyst debug mode is on, I'll tell TT to be very strict, and I'll also use Catalyst::View::XHTML instead of Catalyst::View::TT (which forces serving as application/xhtml)
      • 2009-04-16 10607, 2009

      • aCiD2`
        no, selenium is for javascript
      • 2009-04-16 10611, 2009

      • aCiD2`
        I'm not using that for HTTP tests
      • 2009-04-16 10625, 2009

      • aCiD2`
        www::mechanize::catalyst doesn't even need a server, it's the best way to test this
      • 2009-04-16 10639, 2009

      • pronik
        selenium is rather for site usability, but if you want to just find 503s the other stuff might be fine
      • 2009-04-16 10647, 2009

      • pronik
        as long as those are tap-tests, I don't care :)
      • 2009-04-16 10648, 2009

      • pbryan
        Anyone have a good suggestion where to paste up image scans of album back as corroboration for MB edit?
      • 2009-04-16 10606, 2009

      • pbryan
        Hopefully, something as convenient as patebin?
      • 2009-04-16 10609, 2009

      • pbryan
        s/pate/paste/
      • 2009-04-16 10619, 2009

      • murdos
      • 2009-04-16 10620, 2009

      • murdos
        thoughts?
      • 2009-04-16 10646, 2009

      • pronik
        aCiD2`: test seems to work even though http://perldoc.perl.org/perlop.html#Comma-Operator doesn't accept = as a fat comma
      • 2009-04-16 10654, 2009

      • aCiD2`
        because it's not perl
      • 2009-04-16 10656, 2009

      • aCiD2`
        it's template toolkit
      • 2009-04-16 10603, 2009

      • pronik
        ah, could be
      • 2009-04-16 10608, 2009

      • aCiD2`
        I know that wouldn't work in perl :)
      • 2009-04-16 10620, 2009

      • pronik
        ok, then ignore my comments on github
      • 2009-04-16 10621, 2009

      • pronik
        :)
      • 2009-04-16 10637, 2009

      • aCiD2`
        :)
      • 2009-04-16 10651, 2009

      • aCiD2`
        we need tests, if only to stop you criticizing meaninglessly ;)
      • 2009-04-16 10641, 2009

      • aCiD2`
        murdos: sounds sensible, but I know nothing about how it was done before :)
      • 2009-04-16 10602, 2009

      • pronik
        aCiD2`: got me there :)
      • 2009-04-16 10608, 2009

      • luks
        murdos: I'm not sure about ARs
      • 2009-04-16 10610, 2009

      • aCiD2`
        hehe
      • 2009-04-16 10615, 2009

      • pronik goes back to his readings
      • 2009-04-16 10634, 2009

      • luks
        I wouldn't count adding a performer credit as an artist change
      • 2009-04-16 10603, 2009

      • luks
        but on other other hand the performer credit would be a release change
      • 2009-04-16 10607, 2009

      • murdos
        aCiD2`: how it was planned (and failed): http://wiki.musicbrainz.org/?title=Last_Update_Fe…
      • 2009-04-16 10608, 2009

      • aCiD2`
        relationship should probably change the source (ie, it would be a release change)
      • 2009-04-16 10610, 2009

      • aCiD2` nods
      • 2009-04-16 10614, 2009

      • luks
        it needs some more detailed logic
      • 2009-04-16 10623, 2009

      • luks
        aCiD2`: it depends on the AR, really
      • 2009-04-16 10627, 2009

      • aCiD2`
        yea
      • 2009-04-16 10636, 2009

      • luks
        there are both directed and undirected ones
      • 2009-04-16 10606, 2009

      • luks
        and even the direction is not always consistant
      • 2009-04-16 10608, 2009

      • murdos
        luks: more detailed logic: for ARs? or all this update feature?
      • 2009-04-16 10630, 2009

      • luks
        murdos: for last update triggers based on ARs
      • 2009-04-16 10616, 2009

      • murdos
        based on end point entity type or on some specific AR?
      • 2009-04-16 10625, 2009

      • luks
        specific AR type :(
      • 2009-04-16 10623, 2009

      • murdos
        ok, I'll postpone that and try later to see how it applies to each AR meaning
      • 2009-04-16 10630, 2009

      • murdos
        what about other cases? I'm a bit hesitant about the "album(.release_group)" case
      • 2009-04-16 10637, 2009

      • Munger
        I have found a release that was not only sold as a single disk, but also as disk 1 of a 2 disc set. Should I clone it so that I can add the (disc 1) suffix?
      • 2009-04-16 10645, 2009

      • murdos
        Munger: no, the disc 2 should be titled using "(bonus disc)"
      • 2009-04-16 10604, 2009

      • Munger
      • 2009-04-16 10625, 2009

      • Munger
      • 2009-04-16 10645, 2009

      • Munger
      • 2009-04-16 10646, 2009

      • murdos
        it doesn't matter, since there's an edition with only the first disc: it's implicitly a bonus disc
      • 2009-04-16 10601, 2009

      • Freso has quit
      • 2009-04-16 10609, 2009

      • luks
        murdos: changing album.release_group will possibly change release_group_meta.firstreleasedate, so I'd say it's ok to update the timestamp
      • 2009-04-16 10637, 2009

      • murdos
        ok
      • 2009-04-16 10653, 2009

      • murdos
        btw, what edit type are currently missing for release-groups?
      • 2009-04-16 10656, 2009

      • Munger
        So, I add disc 1 to the first one, which would imply that this was always a 2 disk set.
      • 2009-04-16 10657, 2009

      • luks
        but propagating release event changes to the label is probably going to cause performance problems, no?
      • 2009-04-16 10612, 2009

      • luks
        murdos: moving release to a different release group
      • 2009-04-16 10628, 2009

      • Munger
        murdos, That causes horrible problems when tagging
      • 2009-04-16 10602, 2009

      • murdos
        Munger: I would remove the "disc 1" on the first disc
      • 2009-04-16 10658, 2009

      • murdos
        luks: for release event changes to label, I'm not sure... but it makes sense :/
      • 2009-04-16 10615, 2009

      • Munger
        murdos, It doesn't currently have disk 1. The 2nd disc inthe set even has a different title 'Atomix'
      • 2009-04-16 10615, 2009

      • luks
        murdos: I'd do only the trivial ones for now
      • 2009-04-16 10616, 2009

      • murdos
        I'm not sure it can cause performance problems
      • 2009-04-16 10626, 2009

      • luks
        I think this could be better done in batches
      • 2009-04-16 10610, 2009

      • luks
        e.g. hourly from replication packets (another use case for the DB importer from my lucene soc proposal)
      • 2009-04-16 10637, 2009

      • luks
        hm, and I think PUID changes should not propagate to tracks
      • 2009-04-16 10606, 2009

      • Munger
        murdos, Lok at the front cover of the 2 disc set -- http://trhosking.com/~tim/albumart/00_Untagged/Bl…
      • 2009-04-16 10608, 2009

      • luks
        I'd expect PUID changes are the most frequent changes in the database
      • 2009-04-16 10608, 2009

      • murdos
        PUID: yes, that's not my plan to do it
      • 2009-04-16 10639, 2009

      • murdos
        I just added them to the list in order to have a complete view of the problem
      • 2009-04-16 10648, 2009

      • Munger
        murdos, As opposed to the single disc --- http://trhosking.com/~tim/albumart/00_Untagged/Bl…
      • 2009-04-16 10635, 2009

      • murdos
        Munger: the second disc is titled "Atomix"?
      • 2009-04-16 10624, 2009

      • Munger
        Correct, but when shipped as a set, the artwork was entirely different. I think this qualifies as 2 releases, even though the track listings are identical on disc 1
      • 2009-04-16 10623, 2009

      • murdos
      • 2009-04-16 10611, 2009

      • Munger
        Hmmm. The first disc is just going to have 2 ASINs
      • 2009-04-16 10655, 2009

      • murdos
        that's fine