(everything else has been changed, except the url is still /delete)
ruaok
ishaanshah: ooops, sorry for that. we were trying to debug a filespace issue on paco yesterday and the mapping didn't regenerate correctly. I'll have it fixed in an hour.
reosarevok
outsidecontext: are you maintaining libdiscid now? Wondering if the bug mentioned in MBS-1588 still exists at all
reosarevok: I don't know if I do maintain it :D I did not intent to actually, but applied some changes recently so probably that means I volunteered
reosarevok
haha
I just asked because it's all you in recent history
outsidecontext
about the issue not sure, my gut feeling would be that the underlying issue is probably solved. that bug report is rather old, and there had been quite a few changes afterwards in around 2013. but hard to tell without knowing the actual disc and how the TOC was bad
reosarevok
Ok
Well, improving the error page won't hurt either way
But good to know the whole thing has been improved in the meantime anyway
reosarevok: can be changed if needed, it will probably break URLs for that ticket only.
kori joined the channel
outsidecontext
reosarevok: I really can't tell for sure, the info is very sparse there. The issue on that TOC is really that the total sectors are smaller then the last offset. but to see how this came to be one would need to check an actual disc producing something like this. can also be OS dependent, a glitch in reading the disc or maybe even have been generated with something other than libdiscid.
anyway, I guess improving the error page for wrongly submitted TOCs wouldn't hurt and is basically independent of this.
explaining that the submitted TOC has some invalid format and maybe link to discid documentation would help
tested libdiscid, at least it does not accept the offsets if you feed it the TOC directly
_lucifer
alastairp: two queries regarding the PRs
> My preference is for these error messages to not have a . at the end of them
so only "You have to select a license" right?
second, i am not sure how to add a test case for the cache issue ?
v6lur has quit
v6lur joined the channel
kori has quit
Gazooo794 has quit
Gazooo794 joined the channel
alastairp
reosarevok: off the top of your head do you know if flash messages in MB end with a . ?
hah, and here is me saying ! at the end of a message is a bit naff and we shouldn't use them
_lucifer: does CB have any tests where we mock the cache? I think I have a few of that kind in AB
we could have a test where we test the specific get_x_by_id, mocking the cache and the BU get method, and just put in each of the types of necessary data
e.g., mock cache.get returns None, verify that the db get method is called. mock cache.get returns something, verify that db get isn't called
also, verify that the argument to mock cache.get is expected (e.g. 'artist_[artistid]')
(that's a yes..., I was just checking so that we can do a test that actually loads this data from the musicbrainz database)
_lucifer
yeah, this db will be empty or it has some sample data we can use right away?
kori joined the channel
heyoni has quit
alastairp
that's what I'm asking you
I don't know
_lucifer
oh ok! i'll check that
heyoni joined the channel
it's empty alastairp
kori has quit
d4rkie joined the channel
Nyanko-sensei has quit
kori joined the channel
alastairp
_lucifer: right. I don't know if the tests do anything to load dummy data into the db or not. Perhaps all we should do is mock the call to the brainzutils method too?
I don't like this much, because we're basically mocking everything, but I think the actual method is tested in BU anyway, so perhaps it's not strictly necessary
_lucifer
yeah, i agree. the get_x_by_id method is just choosing between the cache and db