Hey Adam & Arnold, others Couple of things to investigate before closing the door on uuid path.
In our successful effort, we didn’t replace primary or foreign keys. (that was deemed high risk) Keys stayed intact for internal use. The change was adding an extra column and index per table. We handled the backfill incrementally over 4 Sprints ( that was 2 months for us ) . The approach proved simple and uneventful . . . but because we THOUGHT we had a related fail in Sprint 4, we also proved it was reversible if needed. We rolled back the last set of table changes and delivered everything else, then completed the last set of tables in Sprint 5. The real point isn’t which method works, because both will work. The real point is what our end users will experience. Standing up Fineract today is too complex and frustrating, especially for new operators and developers. Every design choice should have a primary objective to simplify installation and "cognitive load" for implementers. One path minimizes ops impact, moving parts and setup risks; the other adds operational burden and set up complexity. We've not really discussed multi-tenancy, but just test case prep and testing is going to be a major effort with snowflake method. Nearly a non-event on uuid path. Ok, that's my "pitch" as "voice of the customer" and with the bit of new information I provided, (NOT replacing any keys), please take another look before your final recommendation. Last: Adam, I've observed you and other members efforts long enough to have confidence in whatever outcome is decided. Thanks for all you and the community contribute. Paul
