Hi Paul, Thanks for the feedback, I really appreciate it.
Generally speaking I agree with you that replacing the PKs with UUID PKs is much more complicated than having an extra column and using that as exposing the data, kind of similar to what the external ID mechanism provides today. However, I think we are the responsible people behind Fineract who have to decide strategically where Fineract should go in terms of architecture. For example, just to talk about the other side. The current sequence generated PKs in Fineract have the issue (as Adam mentioned) that we don't know the PK values in advance so a lot of things in the code are hacked together so this issue is bypassed. While it works, it's certainly a burden of further implementation and maintenance. Another thing we might talk about is that we know there are some organizations who - mostly due to compliance reasons - must not use incrementally generated keys but random UUIDs that cannot easily be guessed. First of all, I think we need to talk about this aspect purely architecturally and where Fineract should go, and next discuss how we get there, because it's certainly not going to be an easy ride. Hope that makes sense. Best, Arnold Arnold Gálovics *CEO, Co-Founder* *+36 30 904 1885* https://docktape.com Docktape Technologies On Fri, Sep 5, 2025 at 4:39 PM Paul <pchristi...@gmail.com> wrote: > 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 >
