Hi Fineracteers, I have been looking at Trafodion integration requirement, and as pointed out by Vishwas, the first obstacle is on lack of flyway support. However, I think this is no big deal, after I have seen that Cassandra had its own ways of dealing with schema version (CassandraJourney), and I can easily implement a TrafodionJourney. The advantage of this approach over flyway is that the flyway method have a drawback (at least from my quick overview of the features): Let me explain: when doing a create table, then dropping columns, and then adding column, and dropping again, and adding again, some (most?) database, like Trafodion, will end up having an internal storage for that particular table not as optimized as it would be if the final table was defined without a succession of adding and dropping columns. I am not sure flyway allow defining/playing just the final end state for a given table, or if no matter what, you always have to successively play all versions one after the other. I plan to support both successive replay of each version, and a direct jump to final version on a TrafodionJourney ecosystem. So that for fresh installs, we don't get a sub optimal storage format. Thoughts?
Also I have another question: The key advantage of going NewSQL is on horizontal scalability. I assume the reason I read that Fineract cn can support small bank, but not medium or large, is that the RDBMS for a single tenant will be the bottleneck? I am guessing that transactions on the checking account must be the most stressed table? If so, I am wondering if at tenant configuration time, we can specify if the tenant we are creating is going to be "small/medium/big", so that DDL associated with stressful table can be adapted and "salted" across multiple servers of the DB cluster. So in a nutshell, I need the DDL to be parameterized based of tenant size. Is that already something accounted for? Thanks in advance for the help, Eric Owhadi
