#musicbrainz-devel

(still more than most editors, though :( )

ok, arrived in paso robles.

time for me to drive teh rest of the way.

I 'll be a few minuts late, gotta get fudz/

bbiab!

luks: What prompted the change to 2.3/utf-16?

all the people in windows freaking out about their tags "breaking"

Silly people

Well, they are using Windows after all

3M edits migrated. looking good.

ah, and its only 23:10 BST, so there is more time.

let me read and ponder for a minuite

sure

does the edit system go back and modify the edit link tables when say an artist gets removed?

yea

well

it removes the link to the deleted artist

do we ever do anything else?

to the old links?

well, we move them if stuff gets merged

just remove ones to deleted entities?

ruaok: no, editing history are merged when you're merging 2 entities

as murdos said, if you merge artist 1 into artist 2, then all edits to artist 1 are moved to be edits to artist 2

so,we would need to "replay" all the edits to the old database to fix things up, right?

we'd need to have some sort of log of what's been merged

we almost have that with the gid redirects

doesn't our edit history tell us this?

yes, it would probably be possible to build a mapping from edit history

here is my goal: if the three of us can figure out what it takes to *make* it possible to fix the migration data, then we'll do it.

otherwise we'll need to save more data/log stuff/whatever so that we *can* make it possible.

murdos: I'm not going back on my word, trust me.

I think we're all a little bit exhaused and overheated.

amen to that. but tomorrow I don't really have anything pressing

so, lets put our heads together to figure out HOW it can be done.

I have some JS stuff to do, but this is more improtant

ocharles: you will have pressing things to do. :)

ruaok: when you get up I will

true.

but there's a good few hours for me to work on things in the mean time

ok, sounds good.

no changes to the migration script though.

thats frozen now.

murdos: what do you think?

sounds good to me too

then we can only fix it after migration?

is it possible to replay the data and replace the data in line later?

hmmm

idea

yes, only after migration.

migration is frozen now.

we do the migration as we do at the moment. this will mean that edit_artist will have links to old artist ids, that are now split into collaborations

surely it would be quite easy to just find all these broken ids, and expand them into artist credit artist ids?

the edit itself will sort of look wrong, but it will have the right links

is this good enough?

you thinking about a post-migration script?

yea

murdos: ?

ocharles: collaborations is just one of the issue

other ones got moved to post-NGS

right, so you want you really want is more comprehensive linking of everything

right

I guess it should be possible to do that in a few queries as well

as I previously said, traceability is really important

sure, I definitely get why it's important

so what I'm thinking is:

do the migration as we do at the moment

then, select all recording ids from edit_recording, and make sure the edit has a corresponding row in edit_release

then, select all edit_release rows, and make sure they have a corresponding edit_release_group

then bubble that up to artist as well

it only leaves label, work and url a bit less linked

but i don't know if that's now too general

I have to check, but since is not only about edit links

some edit types should be migrated in a better way

s/since/this/

lets finishing thinking about edit links.

is ocharles' approach workable, do you think?

I've to think more about it, but it looks like too simple

hmm. ok.

I'd prefer the "replay" scenario

the improvement of problematic edits should be easier since we dont go back and change the edits, right?

ruaok: as murdos said, the edits do depending on other underlying data though

so just rerunning a migration could be incorrect

ruaok: indeed. the embedded json might change

ok

ok, then lets think about how a replay script would work.

we would only replay new edits since NGS switchover, right?

before we do that, I think we need to be very clear about the problems we are trying to address

i'm still hazy on exactly which edit types need their migration changing

should we create a page for that?

the linking I can understand the problems with

but as far as I understand, the data in the edits is correct, as it just matches the edits in pre-NGS

let me check my open tickets

e.g. http://tickets.musicbrainz.org/browse/MBS-1844

1844 I can see being fixable after migration

hrm

no, might not work

though with a tiny change, it could be easier to fix that after migration

(If the old edit has nothing for AlbumId, then we can stick -1 as the release_id as a marker for now)

I trust you on this one, I can't really say

MBS-1846: I think the old value on http://musicbrainz.org/show/edit/?editid=11484506 should be displayed as an artist credit

what do you think?

that's what I was saying I can spend tomorrow working on

but rob doesn't want me to change the migration script

doing that after migration is a bit more difficult

We'd have to keep the collaboration table around, along with an artist merge table (for all merges that happened after NGS launched)

and then go back and try and piece things together. not sure it'd work so well

if we change the migration script, we can't test it before running it live.

I can test small amounts of edits

and if we decide we must change the script, then we need to postpone the launch

but probably not the whole edit database

The changes here would affect only edit types that have artist credits in them. that may be a small enough set to be an amount of edits I can do a full test on

how long will this change take?

murdos: what other edit types need fixing

?

I need to build some sort of artist id -> artist credit mapping in memory, then wire that into the necessary edit types.

I don't think the historic edit types expect to have artist credits in them, so those need to have the upgrade bit changed, along with how they are displayed

after more thinking, I think behind MBS-1846 there are 2 issues: 1. displaying old/new values as artist credits 2. move editing history of a collab artist to each involved artists

2 can be done easily

I would personally want 2 to be done, and with 1 we'll have to put up with displaying just the name and having it appear as though the artist is deleted

1 too but not that much

my solution to 2 is http://chatlogs.musicbrainz.org/musicbrainz-dev...

ocharles: but you would do that post migration, right?

right, it'd be a new script

so won't be able to handle artists merged post NGS?

I think I could probably write that script now

Then we can run it before those edits make it in

ok, so right after migration?

right

ideally I'd want to run it right after upgrade edits

yep, that sound good

murdos: are those all the issues?

there are http://tickets.musicbrainz.org/browse/MBS-1855 and http://tickets.musicbrainz.org/browse/MBS-1843 too

ocharles: can you please make a wiki page (or something) that keeps track of what we've decided?

have we decided anything yet? :)

lets record what has been decided before moving on to the last two issues.

from what I understand: expanding artist credits to just links is OK, and the standalone recording problem can be fixed with hacking a -1 into the script

just jot down possible approaches to fixing theses problems as well as listing the problems.

does that sound right to everyone else?

ocharles: it seems yes. so 1 of MBS-1846 is won't fix, right?

i'm afraid so

I think we can live with that

ok, so far we have:

> expanding artist credits to just links is OK, and the standalone recording problem can be fixed with hacking a -1 into the script

lets move on to 1855

(for the record, -1 is just a hack to ease the final fix post NGS)