I would add also a precondition to check that picked_by_id does not exist.

picked_by_id

fk_picklist_item_picked_by_id_person

Sorry, I didn't get a chance to review this until today.

The rename column feature might be a bad idea as it probably isn't supported by all versions of MySQL/MariaDB causing potential community support issue. In fact, I've encountered issues with MySQL 5.7 where the rename doesn't work if there's a foreign key on the column. Which is exactly what we have here.

Fwiw, I was not actually expecting you to go through with the change based on my second thoughts. So apologies for creating more work. A day after I made that comment about picker -> pickedBy, I realized that either or both columns could exist alone or together.

Picker vs picked by represents different users at different points in the pick task state machine. A picker generally represents the original person assigned to the pick task and pickedBy could be assigned the same value when the pick task is completed. But there's also a use case where the two values are different in the case of some other user taking over the task and doing it themselves. In either case, picker or pickedBy would be fine. But I did realize that picker alone or with pickedBy does make sense.

So we have a few options here:

1. Leave it as-is
   a. Deal with bugs and community support if/when they surface
2. Use both picker_id and picked_by_id
   a. Remove the rename column changeset in favor of adding both columns.
   a. Create a new changeset for adding picked_by_id, so we have both.
   a. Manually remove the invalid changelog executions from dev servers (OBDEV3)
3. Use just picker_id as originally designed
   a. Remove the rename column changeset to leave just the picker_id column.

cc @alannadolny @awalkowiak

@jmiranda as it was discussed on the tech huddle channel, if this is related to MySQL 5.6, let's leave it as is. However, if we'd like to be safe here, there might be a 4th option (easier than 2nd and 3rd) - we could move out the drop foreign key changeset to a separate changelog file and run it before this rename (to be sure it will be run first).

@alannadolny Can you explain what objectQuotingStrategy does and why we should use it? This would be good to add to database migration guide.

@awalkowiak I could have sworn you wrote a best practices guide for generating changelogs using Liquibase / Database Migration plugin, but I cannot find it anywhere.

This might be the ticket which looks like it's still in-progress.
https://pihemr.atlassian.net/browse/OBGM-90

I used the dbm-changelog-to-groovy command to create a groovy changelog from XML changelog. This is the exact output from this command, so all of the options are probably defaults from XMLs.
objectQuotingStrategy:

onSqlOutput:

@jmiranda I was working on a guide for generating changelogs using Liquibase / Database Migration plugin in one of other tickets, or rather I had to try to do it automatically and document the process around it (scope of OBGM-90 as a part of the OBPIH-6114). However, I ran into some issues, and it was not working as smooth as expected, and I decided to unblock the OBPIH ticket and I dropped this scope from the feature ticket and move it to the OBGM-90. I think I marked it as in progress, because I wanted to add some more thoughts and comments in there and the ticket itself got lost in the backlog

Same question for onSqlOutput.