#musicbrainz-devel

ruaok: ah. looking at my feed from github, it looks like a subsequent push ended up deleting it

I moved the tag.

and then I remember using it. someplace else.

there's several 'mayhem created tag v-2012-10-15-schema-change' followed by 'musicbrainz deleted tag v-2012-10-15-schema-change', but the latter is the most recent

I suspect you used it before one of the deletions

odd.

point stands, at present it's neither place

I think the thing to do is push it to git.mb and let it get automatically mirrored to github

let me push it to git.mb too

oh yeah, it didn't let me push it to mb.

rump:~/musicbrainz/musicbrainz-server->git push mb v-2012-10-15-schema-change

fatal: The remote end hung up unexpectedly

and since we switched things over, I assumed that I should push to github.

not sure what to do about it.

hopefully my push worked, I guess

there's been neither announcement nor instructions on how to switch from git.mb from github

so git.mb is still the official source

Both https://github.com/metabrainz/musicbrainz-serve... and http://git.musicbrainz.org/gitweb/?p=musicbrain... list the v-2012-10-15-schema-change tag, I wonder why it's not working

navap: we've pushed it to both at this point :)

github says uploaded 10 hours ago though

git.mb says 9 hours

I suspect that's the date of the commit

or it made it when it was first tagged, which was about then, later deletions notwithstanding

git.mb definitely didn't have it before a couple minutes ago when I pushed it there :)

ah, I think it's using the tag creation time, which is independent of when it was pushed

the discrepancy is probably that github may have used the original incorrect tag

hello!

moin moin

time for some fixing of things

ianmcorvidae: have you done anything related to these broken edits?

I have note

not*

other than vaguely thinking about them

haha

I think for the comment == null situation changing the edit class is the way to go: we've essentially established that null and '' are the same thing, and that '' is the one we want to store, so it makes sense to turn null into it in our perl code

for the whitespace I'm still not sure

the whitespace one only concerns a few edits, so either I manually edit those or I script whatever I would do manually.

especially as our big problem there is on artist_credit.name, which is a result of join phrases, which are harder to futz with

what's hard is properly defining where such editing should happen, I think :)

no, not really.

well, it's hard to define in a sql query, but it's easy if you can parse the json.

well, any one case is easy, I think

it's just non-empty join phrase at the end of an artist credit.

e.g. "if the last join phrase of a given artist credit matches \s+ turn it into ''"

I suppose if that's the only one we're having trouble with

incidentally, we may need to fix the artist credit editor(s) to stop doing that, as well

select * from edit where status = 1 and data like '%join_phrase":" "%'; reports 9 results. ofcourse " " may not catch all of them.

that also catches cases where that's not the last join phrase, potentially

sure, but that just means even less edits are affected.

I'm going try and script some queries.

k

but of course don't do any updates yet :)

no, I can do that here on my dev machine.

I have 10 edits here matching the sql query above.

ianmcorvidae: do you know if there is a ticket for this specific issue?

I don't think there is

because the only people who could have filed it are people who get modbot emails, and none of us have :)

that and people anxiously awaiting for their edit to apply, frantically hitting F5 on the edit page

did somebody test upgrade from the last schema change release?

because I don't think it works

ERROR: function controlled_for_whitespace(character varying) does not exist

luks: ostensibly it was tested; I did not personally

from what I can see, it's only created in sql/updates/20120731-constrain-catno-whitespace.sql and CreateFunctions.sql

none of which are used in the upgrade script

yeah, that does sound correct

I guess ruaok's testing wasn't started from the v-2012-05-15-import-fix tag :/

oh, that was the actual release tag?

ah, misunderstood

v-2102-05-15-schema-change was the original release tag but 2012-05-15-import-fix is where you can actually run imports on the may schema change

what I mean is the testing for that should have been: check out v-2012-05-15-import-fix, import the 20121013 dump using that, then run the migration

ianmcorvidae Regression http://tickets.musicbrainz.org/browse/MBS-5471 ?

hm

ERROR: duplicate key value violates unique constraint "artist_name_pkey"

now it's getting more interesting :/

luks: which sha1 are you migrating from?

we fixed a bug with that and updated the tag, it wasn't calling SetSequences

I'm using mbslave, not mbserver

mbserver is only used for inspiration

ah

and I'm using the latest master

well, we updated upgrade.sh to call SetSequences; I don't know if you've updated mbslave accordingly

grrr, unicode and perl :(

oh, I didn't notice that

(the artist_name pkey issue is that one script does inserts to artist_name but replication doesn't update the sequence for artist_name.id, so it tries to insert with IDs that are too small)

(solution: set the sequences that replication didn't)

thanks, that helped, but I think now I'm done, postgresql 8.4 is no longer supported :(

I'll have to drop and reimport

ijabz: not sure what's up there, looking into it now

ijabz: seems to only happen in the RE, which is odd :/

ianmcorvidae: I think I did a fetch while the wrong tag was in place.

How do I get the appropriate one?

git tag delete and then fetch again?

adhawkins: a new fetch should do it, I'd expect, but if not delete the tag first

Still seems to point to b3b9ed2e25d53499a7dad1b81cc4e36026703e1f

Blog says it should be 5bd71d211dceb25a7a0d545a14cb3273e3e89f19

I'm doing this from github.

yeah, it's definitely 5bd7etc.

What's the git:// URL for git.mb.org?

I'll switch back, just read that's still the 'official' repo

hm, I forget, I have the ssh URL at this point

Ok, I'll go digging.

luks: where is 8.4 not supported?

Doh.

For future reference, 'git tag delete tagname' doesn't delete the tag, it creates a new tag called 'delete' that points at tagname :)

hah

Is 3.5G too small to do an upgrade in place?

Blog posts recommends 10G...

nikki: the upgrade scripts don't work in 8.4

particularly sql/updates/20120220-merge-duplicate-credits.sql

LINE 6: SELECT array_agg(artist_credit ORDER BY artist_credit AS...

:(

so reimport is the only way to go

Well, that's obviously a bug then

So what would happen is that it would be the right report :p

it seems like it would be possible, given that debian stable and ubuntu up to 11.04 have 8.4 by default

I mean as the default version for postgres, I suppose they might have multiple versions available if you specify a specific one

I mean, if we say it works and it does not, it's a bug

And the answer is probably either fix it or stop saying it works

we should at least warn customers if we're suddenly going to stop claiming to support 8.4

Well, yeah, I just didn't want to say fix it or fix it :p

we should get our shit done earlier than three days before release, and then do more testing than the bare minimum we did

(heh, three days before release, I say like that was actually when things were done)

we should get our shit done earlier than the day we planned to release :P

So is there any point me trying an upgrade on 8.4?

adhawkins: well, you could then report the bug? :p

Dunno

reosarevok: I also have the issue that I might not have enough disk space to do an in place upgrade anyway.

I'll give it a go and see what happens.

If the carton deployment ever finishes...

heh

warp / ocharles / ianmcorvidae: could we try to get this released soon? hopefully in the next release, people keep having issues with this stuff http://codereview.musicbrainz.org/r/2199/

ianmcorvidae: I think I have a fix for the joinphrases. I'm going to try it locally now.

warp: k, then stick it on gist or such for review?

sure

ianmcorvidae: success in my test. approving edit 19206591 fails before the patch, succeeds after the patch.

warp: I'm more concerned about breaking correct edit data

however, good that it fixes the problem :)

ianmcorvidae: do you have a schema upgraded copy of musicbrainz running?