Hi guys, I am wondering whether these additional data is primarily there to be stored and fetched or these are fields to be used for fetching a particular transaction? It really depends on the use case which one is to be favourable.
Having an additionalFields map (probably represented as a json at database side) is dynamic and flexible, but not best for filtering as indexing is not straightforward. Having datatables for transaction entries can be proper, however the question is whether the datatable model to be used for all kind of transactions or should the transaction type to be used as well for mapping? Technically it is possible: application_table_name is m_savings_transaction table, entity_subtype is the savings transaction type. Since the datatables were introduced for the purpose of extending an entities data model dynamically but still in a structured way, i think it could be a good candidate here. Mostly if these fields will be used for fetching / filtering a particular entry. The challenges here would be at the moment the transaction type is stored with the ordinal value of the enum, so in the database the entity_subtype will store sometimes as a string, sometimes as a number. But this is not a blocking issue, just....not consistent… James: Can you help me to understand more about the original idea and the performance problems? If datatables were used and the fields - which are used for filtering - are indexed, there should be no problem. Regards, Adam > On 15 Jun 2023, at 18:52, James Dailey <[email protected]> wrote: > > Devs - > > There's a need to have the transaction concept enhanced in the Savings > Account module. There are some discussions on tickets, but I'd like to > surface them here to see if anyone can provide additional design thinking. > > The implementation of the Savings Account module today allows for > transactions, and by using the datatable extension, you can have additional > details about such transactions. However, this design does not scale well > and lacks flexibility. > > A few people have thus started working on this with the idea of leveraging > datatables. That is, to attach datatables to the transaction entity for > savings account transactions of all types, rather than a datatable to the > savings account (again, that original design does not scale well in terms of > performance). This gives rise to additional questions. Should we use the > Datatable concept here? Or, create a new thing? Can we gracefully migrate > and not have a breaking change? > > Just to set this context more, the Savings Account is really the only > Liability Account concept we have. (i.e. Liability of the Bank to the > Customer). The module can be used as a Savings Account, Share Account > (credit unions), Wallet Account, and similar. See also discussion of need. > [1] > > https://issues.apache.org/jira/browse/FINERACT-1911 > > "Currently, (in fineract) we capture transactions using a fixed set of > attributes. However, as mentioned by Peter Santa > <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=peter.santa> > there may be cases where additional transaction-related attributes are > required, such as debtorIban, creditorIban, correlationId, and > settlementDate. Adding these attributes directly to the core Transaction > entity may not be the most flexible and maintainable solution, as it can lead > to data model modifications and potential compatibility issues. > Assuming that the additional transaction related attributes will be limited > in number and not over complex, I would propose implementing a flexible > schema approach using the concept of additionalAttributes. By introducing a > Map<String, Object> field named additionalAttributes within the Transaction > entity, we can dynamically capture and store any additional attributes > specific to each transaction. This approach allows us to accommodate custom > attributes without modifying the core data model, ensuring data integrity and > simplicity." > (mkkor) > > > [1]https://lists.apache.org/thread/jdyqoqxmohftvshc0q9y6fc0v827fqjq > > > > On Wed, Jun 14, 2023 at 9:53 AM Ed Cable <[email protected] > <mailto:[email protected]>> wrote: >> Thanks Bharath for creating those tickets on the Mifos UI side - I will see >> how we can go about getting that work done so there continues to be a >> balance between what's available in Fineract back-end also have a reference >> user interface for it as well. >> >> Ed >> >> On Wed, Jun 14, 2023 at 1:27 AM Bharath Gowda <[email protected] >> <mailto:[email protected]>> wrote: >>> Hi All, >>> >>> Great to see some search query changes happening on the savings transaction >>> level >>> >>> Have created Mifos UI tickets for the following tickets so that community >>> users using Mifos UI will get benefited of these features >>> https://issues.apache.org/jira/browse/FINERACT-1747 >>> https://issues.apache.org/jira/browse/FINERACT-1912 >>> https://issues.apache.org/jira/browse/FINERACT-1910 >>> >>> >>> Regards, >>> Bharath >>> Lead Implementation Analyst | Mifos Initiative >>> Skype: live:cbharath4| Mobile: +91.7019635592 >>> http://mifos.org <http://mifos.org/> <http://facebook.com/mifos> >>> <http://www.twitter.com/mifos> >>> >>> >>> On Mon, Jun 12, 2023 at 9:14 PM James Dailey <[email protected] >>> <mailto:[email protected]>> wrote: >>>> On this topic, there are some discussions around the current tickets and >>>> at least one proposed PR. >>>> >>>> The idea of extending the functionality of the Savings Account (Current >>>> Account) has long been on the roadmap, so it's good to see some progress. >>>> As we move forward, let's keep in mind, >>>> a) Incremental improvements are good (don't impact other users while >>>> adding functionality in a smart design) >>>> b) backwards API compatibility >>>> c) performance >>>> >>>> Also, I note that although the Mifos UI projects do try to stay up to date >>>> with the latest on Fineract, they are NOT part of this project, so the >>>> behavior of the APIs can only be seen in postman or some other test tool. >>>> >>>> >>>> >>>> On Wed, Jun 7, 2023 at 7:53 AM James Dailey <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> Bringing to top of list >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message --------- >>>>> From: James Dailey <[email protected] >>>>> <mailto:[email protected]>> >>>>> Date: Wed, Apr 5, 2023 at 9:30 AM >>>>> Subject: Fwd: Fineract - Feature Request - Savings Account related >>>>> Trensactions and Data Tables >>>>> To: James Dailey <[email protected] >>>>> <mailto:[email protected]>>, <[email protected] >>>>> <mailto:[email protected]>> >>>>> >>>>> >>>>> Art - Would you please forward to your backend fineract people and make >>>>> them aware of this effort? I want to ask you if they can be involved >>>>> in this mini-project to be delivered by mid-May. >>>>> >>>>> >>>>> >>>>> >>>>> ---------- Forwarded message --------- >>>>> From: James Dailey <[email protected] >>>>> <mailto:[email protected]>> >>>>> Date: Wed, Apr 5, 2023 at 9:22 AM >>>>> Subject: Re: Fineract - Feature Request - Savings Account related >>>>> Trensactions and Data Tables >>>>> To: <[email protected] <mailto:[email protected]>> >>>>> >>>>> >>>>> Thanks Peter. These are very welcome from my perspective. I hope others >>>>> jump into the discussion and make suggestions or share their designs. >>>>> >>>>> TL;DR Add data tables to transactions in savings account module and >>>>> filtering of transactions. >>>>> >>>>> I think it fair to say that this relates to the conversation about a more >>>>> robust “current account” >>>>> https://lists.apache.org/[email protected] ( misnomer >>>>> "savings" account) >>>>> >>>>> Such improvements you’ve ticketed would be a first incremental step in >>>>> expanding the functionality. >>>>> >>>>> +1 >>>>> >>>>> Additionally, I think this would benefit from having a ticket that brings >>>>> these tickets and others together. So I've opened a parent ticket: >>>>> https://issues.apache.org/jira/projects/FINERACT/issues/FINERACT-1917 >>>>> >>>>> >>>>> >>>>> >>>>> On Wed, Apr 5, 2023 at 6:39 AM Peter Santa <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> > >>>>> > Dear Community, >>>>> > >>>>> > We have some requirements collected, regarding to Savings Account >>>>> > Transactions, Data Tables, and to their combination. >>>>> > >>>>> > Would someone consider it as useful for the Community, and pick it up >>>>> > for development? If yes, feel free to reach out for a discussion, to >>>>> > avoid misunderstandings, and to align the solution concept. >>>>> > >>>>> > The related, currently existing tickets: >>>>> > >>>>> > Transactions >>>>> > >>>>> > https://issues.apache.org/jira/browse/FINERACT-1912 >>>>> > >>>>> > Data tables >>>>> > >>>>> > https://issues.apache.org/jira/browse/FINERACT-1747 >>>>> > >>>>> > https://issues.apache.org/jira/browse/FINERACT-1910 >>>>> > >>>>> > https://issues.apache.org/jira/browse/FINERACT-1916 >>>>> > >>>>> > Transaction+data tables >>>>> > >>>>> > https://issues.apache.org/jira/browse/FINERACT-1911 >>>>> > >>>>> > https://issues.apache.org/jira/browse/FINERACT-1915 >>>>> > >>>>> > https://issues.apache.org/jira/browse/FINERACT-1916 >>>>> > >>>>> > >>>>> > Best Regards, >>>>> > >>>>> > Péter >>>>> -- >>>>> Sent from Gmail Mobile >>>>> -- >>>>> Sent from Gmail Mobile >> >> >> -- >> Ed Cable >> President/CEO, Mifos Initiative >> [email protected] <mailto:[email protected]> | Skype: edcable | Mobile: >> +1.484.477.8649 >> >> Collectively Creating a World of 3 Billion Maries | http://mifos.org >> <http://mifos.org/> <http://facebook.com/mifos> >> <http://www.twitter.com/mifos> >>
