Potential mentions migrate bug

[brendanheywood]

Simon this may be nothing but worth a quick check:

http://www.thecrag.com/climbing/australia/mount-wellington/area/297016725/ascents/by/brendanheywood/?sortby=when,desc

I have other other ascents on the same day which are properly linked, I think this may have been the first day I pre-emptively added @ with ahead of time. I'll propbably just end up fixing it manually once you've had a look, I just wanted to make sure it wasn't something deeper wrong

[scd]

I presume the with field just has the '@' symbol in it. It is probably easier for you to check by editing the ascent. If there is anything more then there is something deeper. Do you want me to check the raw database fields?

[brendanheywood]

There is almost no chance I manually entered a '@' into the with field. I would have left it blank or entered 'Chris' or @cee who I was with that day. I ticked other problems that same day also with chris which are linked properly. The raw DB field just has a '@' so whatever data it had seems gone. I'm not concerned about me personally I'm worried about more wide ranging data issues.

mysql> select withclimbers from Ascent where Id = 566806008;
+--------------+
| withclimbers |
+--------------+
| @            |
+--------------+

I also found this further along in my log book:

http://www.thecrag.com/climbing/australia/glasshouse-mountains/tibrogargan/area/12228883/ascents/by/brendanheywood/

The number matches sgodwin's account but no idea why these particular ascents didn't get linked properly. It's like in some cases the number part has been omitted leaving the @, and in others the @ has been dropped leaving only the number.

[scd]

Yup this is potentially very troublesome, because if there is a problem with migration then fixing the data means getting it from an archived database (monthly). Whatever went wrong it seems isolated to you for ascents.

SELECT A.ID,A.WithClimbers FROM Ascent AS A WHERE A.WithClimbers = '@'

+-----------+--------------+ | ID | WithClimbers | +-----------+--------------+ | 566805945 | @ | | 566805957 | @ | | 566805969 | @ | | 566805981 | @ | | 566805993 | @ | | 566806008 | @ | +-----------+--------------+

SELECT A.ID,A.WithClimbers FROM Ascent AS A WHERE A.WithClimbers REGEXP '^[0-9]+$' AND LENGTH(A.WithClimbers)>4

+-----------+--------------+ | ID | WithClimbers | +-----------+--------------+ | 212109411 | 11525106 | | 212109423 | 11525106 | | 212109429 | 11525106 | | 212109435 | 11525106 | +-----------+--------------+

Are there any examples of correctly migrated ascents in your logbook? It would be good to know if it was a systemic error for all migrations or an edge case with specific fields.

Also, with the failure cases have you updated these ascents since the release. I want to rule out a bug in the update process, which I just tested and seems ok.

So there is not a major impact to ascents. There were not many uses of mentions in the database before the release, but potentially there might be the odd problem in other fields. I did test the migration so it is very confusing how this happened and even more confusing how there are two separate failure cases. My thinking is that there is some edge case (eg space after the @ - I have not tested this btw) which cased an error in the migration.

I think we can close this issue, but just keep in mind the discussion in case we find other similar issues in other fields.

BTW, these are the fields I migrated on:

'ascent-comment' => 1, 'ascent-with' => 1, 'description' => 1, 'comment' => 1, 'history-climbers' => 1, 'photo-description' => 1, 'photo-climber' => 1, 'photo-photographer' => 1, 'profile-message' => 1,

Finally this issue leads me to think of two process improvements for future:

• explicitly store a pre release database archive for the long term. Currenlty only monthly is stored long term. There are daily archives, but they are overwritten once a week.
• have a tighter policy on logging the before and after data state when migrating the data.

[brendanheywood]

Ok well if it's mostly me affect thats cool, I'll go fix them manually.

The second set, the unlinked '11525106' was a very old tick and I entered it as 'sgodwin' and not as 'sgodwin'.

I have plenty of examples of both types being migrated, so I'd say > 90% are fine. I'm happy to close this as it doesn't seem to be more widespread, and as you say just keep it in mind for future migrations to be a bit more cautious and keep more history