El dom., 10 may. 2020 a las 14:22, Michael Vorburger (<m...@vorburger.ch>) 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. >> > > 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 concatenating strings but use just java streams . Does sense to open a jira ticket for that? > 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. 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
