@tkuah I've been looking into the approach we discussed where we would:

1. Update Plan to use the new uid column exclusively, and drop id.
2. Update code references to use FixedItemsModel version of Plan.

That approach will take quite a bit more time, my concern is that I won't be able to hit the 19.2 deadline of having everything wrapped up with those additional steps. For that reason I would delay dropping the old id [Plan] Remove old plan associated columns and d... (#571424) until after we have migrated to using FixedItemsModel as part of the cleanup work. That way we should have resolved the concern of primary id issues with the cell local Plan table, that unblocks the cells migration and cleanup will follow as soon as possible. Does that make sense to you as well?

I also investigated another option we briefly discussed was making incremental small updates to switch to the FixedItemsModel. With that approach we could bypass some of the extra work in replacing the id usage with uid by directly moving to FixedItemsModel. However after a deeper look at the related models it was not possible to update atomically or by first updating reads then writes without the risk of conflicts. Mainly the concern being multiple nodes and rolling updates causing conflicts in high traffic tables between usage of the two different id fields.

@div.ya Sounds good. I was thinking similarly to return an explicit error and handle it directly in Gitlab. Thanks for taking a look into this! 🙏

Florian Jedelhauser (4cb09155) at 18 Mar 14:05

... and 269 more commits

@hustewart Right, good catch! I've updated for the next milestone.

@l.rosa Can you please review again as well, approvals were reset when switching to milestone 18.11. 🙏

Florian Jedelhauser (a19c3114) at 17 Mar 18:21

@hustewart I rebased and the pipeline ran successfully, are you able to merge? 🙏

Florian Jedelhauser (b5b75bc9) at 17 Mar 14:00

... and 2142 more commits