On Sun, 10 May 2020, 20:01 Giorgio Zoppi, <[email protected]> wrote:
> > El dom., 10 may. 2020 a las 14:22, Michael Vorburger (<[email protected]>) > escribió: > >> Buongiorno (?) Giorgio! >> > > Buongiorno Micheal, > I have attached the report in the JIRA, i will take further investigation > later against the old UI app. > >> >> Cool! We're excited to see you explore >> https://issues.apache.org/jira/browse/FINERACT-969. >> > > >> >> >>> As for the Parameters Query, the problem is the implementation itself. >>> It will make sense to discuss a thinly layer for query separation. In the >>> .NET world we have Dapper. https://github.com/StackExchange/Dapper used >>> in StackOverflow. I dont know if there is a similar stuff in Java. >>> >> There are many, out there some are really cool. > >> I'm not 100% sure what you mean, but I believe you may be making the >> point that the use of an ORM (Object Relational Mapping) framework can help >> prevent SQL Injection. I agree with this! FYI Fineract already uses one ( >> https://openjpa.apache.org, but note >> https://issues.apache.org/jira/browse/FINERACT-849 for potentially >> possibly maybe switching). Fineract only uses ORM for write. Much read is >> still direct SQL. >> >> It was related to ORM, but in more general to get all queries in a place > and using Java Streams, the renderer will take care of doing paramtetric > query for example: > https://github.com/speedment/speedment . So you avoid that your student > crafts queries > We kind of have to develop the framework approach rather then queries written as usual. > concatenating strings but use just java streams . Does sense to open a > jira ticket for that? > I have started using Java Streams, most of the read is happening over the sql native calls because of complex relationship defined. Speedmentn streams are nice. > > >> FYI we have a GSoC student who is going to work on >> https://issues.apache.org/jira/browse/FINERACT-854 and >> https://issues.apache.org/jira/browse/FINERACT-853. I would expect that >> certain of the issues your work on FINERACT-969 will uncover will be fixed >> by FINERACT-854. >> >> If I were you, I would not wait for that work to complete, but instead go >> ahead, create JIRA bugs for everything you identify (best as sub-tasks >> under FINERACT-962, perhaps?) - and then later help us verify that the >> FINERACT-854 work actually fixed (some.. and which) of what you'll find. >> Makes sense? >> > Yes, glad to help. > >> >> >>> I see the real meat is still old fineract, instead the fineract-cn is >>> still work in progress. So i will install the old one. >>> >> >> Contributions to both are obviously always very welcome... :_) >> > My idea about fineract-cn is that it doesn't make sense to craft in Java > (i am sorry). It is too verbose for doing microservices, i would prefer > another platform as .NET or Go. I don't see much work on cn yet. > Whole idea of the microservices is to allow any platform written in any language. But at present this seems like a barrier. Thanks for your amazing work in fineract.dev, it would be nice if some > expert will prepare an appliance to be used in virtualbox. So it will speed > up the testing and learning about fineract. > > Best Regards, > Giorgio >
