search

Fermat-ORG / fermat-framework

This is the Fermat Framework described on the first Fermat whitepaper. The Java Framework, Android Framework, Linux Framework, and all platforms are here. This project is currently paused until we put the network infraestructure in place. Later this work will be resumed to put this client-side infraestructure to work with the new set of networks.
https://drive.google.com/file/d/0B02V15ufCwR3UDNER3l2WGVmcE0/view
Other
2 stars 2 forks source link

Is there a need for a new addon wrapping a non-sql database? #5767

Open Luis-Fernando-Molina opened 8 years ago

Luis-Fernando-Molina commented 8 years ago

Discussion started on slack like this:

sytolk [6:40 PM] I see that its have DAOs and fermat Database layer to persist data in sqlite. Its have easy way to do that if you use JOOQ I have use it in server its have maven and gradle plugin http://www.jooq.org/doc/3.7/manual/code-generation/codegen-gradle/ that generate POJOs and DAOs from DB structure automatically and this will work in Android too (I have not tested on Android but its have gradle plugin)

https://github.com/etiennestuder/gradle-jooq-plugin

https://www.youtube.com/watch?v=jR4OtA8kArQ (edited)

sytolk [6:48 PM] Can I have sqlite.db SQL export for the server node. I dont know if Android app will use sqlite ?

acosta_rodrigo [8:36 PM] doing the DAOs classes is one of the most time consuming part of some plugins...if you can investigate if this alternative is suitable would be a great time saver for all

yayotron [11:25 PM] I doubt we can get that to work, at least not without reestructuring the database manager plugin or getting rid of it. The way JOOQ works is way different than our currently database management structure.

franklinmarcano1970 [11:38 PM] besides that, that kind of ORM tools even help much, our data model scheme is aimed directly working with the SQLite database and not oriented class and from there create data schemas, but would not hurt more alternatives.

furszy [11:44 PM] Sorry, I just read it. Last year i proposed the same idea, a mapper-object relationship embedded database like Perst without success for time reasons. Now is a good time to improve our database-system with a nice document explaning every future change. 2

franklinmarcano1970 [11:48 PM] :+1:

----- Today April 2nd, 2016 ----- acosta_rodrigo [12:27 AM] uploaded an image: sql.jpg Add Comment sytolk [7:04 AM] I have switch using ORM from Hibernate to Jooq 3-4 years befor and think its better but if you have experience with other ORM @furszy ?

luis-fernando-molina [7:06 AM] The current database addon is a wrapper of an sql-like database abstracting the rest of the plugins of which one exactly and at the same time of the operating system. This doesn't mean Fermat could not have an alternative non-sql wrapper that plugins might use. The condition to do that is the same: it should abstract plugins of the underlying technology specialty if that technology is os dependant. Those are my two cents to this discussion. (edited)

Luis-Fernando-Molina commented 8 years ago

@sytolk @furszy @lnacosta @acostarodrigo @darkestpriest @franklinmarcano1970 @Yayotron

Luis-Fernando-Molina commented 8 years ago

sytolk [7:13 AM] Jooq do the same work and much more. You can easly switch using every open source RDBMS

luis-fernando-molina [7:14 AM] As this discussion doesn't seem to have a quick resolution I suggest moving it to a github issue to be seen by a broader audience: https://github.com/Fermat-ORG/fermat/issues/5767

sytolk [7:15 AM] source code generation let developer to change DB structure without to rewrite java code this save time

[7:18] If I have current sqlite SQL export I can easy done Jooq dependent module that do the same job like current database module :)

Luis-Fernando-Molina commented 8 years ago

Jooq do the same work and much more. You can easly switch using every open source RDBMS

knowing what we have now, what would be your suggestion to improve it? @sytolk

replace what with what? where exactly? pros / cons?

I havent gone deep into Jooq, if you know it please tell us: what would need to be changed in order to use it on plugins?

sytolk commented 8 years ago

When I was a junior developer I have project with my implementation of Json parser and my PM say why not use any of the existing open source parsers ? I have tell that my parser is better :) and the PM say ok publish it if its have more stars we will switch using it.. I remember I was very disappointed :) But the true question is if its have developer that have open source library with Apache 2 license like @lukaseder why not using it and if its have bugs and issues we can contribute to this project?

sytolk commented 8 years ago

Its need to set @Deprecated annotation to old database module and start using new one :) Do its have dependency injection framework ?

sytolk commented 8 years ago

I see that the question is for "no sql" database. Sqlite is embedded in node app its have no socket connections to this DB. If you have a plan to use No SQL DB like Mongo DB the question: is there need to pay for the DB hostind ? No its not need No SQL DB

furszy commented 8 years ago

@sytolk i used to work with non usuals ORM in the past and we can not rely on a not proved in a large scale system like this third party library for a module as critical as the database system and deprecate the one that is operating right now, If you want to propose a structure of the new addon and if we are all agree with your proposal we will help you to build it and test it for a while until we are 100% secure that the module is working well and include it in Fermat. Meanwhile i will open an issue to talk about optimizations in our database-system.

sytolk commented 8 years ago

@furszy I not think so :) the main goal of the ORM is to not let developer to write plain SQL.. this is equal to not let developers to write SQL errors that java compiller cannot show. If you think that the current DB module is proved and relayable.. maybe but what happened if you change DB table structure and forget to change some of the current Java hardcoded static column names? This is the reason that Java Pojos and DAOs needs to be generated. This will let developer to change DB structure and Java compiller will show him if its need to change some of the setters/getters methods names. If you want to not let developer to compille production app that produce SQL statement error you can use ORM. If something is possible it will happened :)

furszy commented 8 years ago

@sytolk i agree with you in use ORM, That is not in discussion obviously we need to improve in this way, The main discussion here is if we use the third party library that you propose we have to test it and verify the source code of the library before include it in Fermat because we can not rely on a third party library that can be modified for other person outside Fermat in a addon as critical as the database-system. That is the main goal of the community, we have to take care of Fermat health and the database system is one of the bases that we have to look closely. The new addon have to follow the basics connection concepts of our database-system, providing a interface and abstracting the database connection.

sytolk commented 8 years ago

@furszy Jooq is tested and verified from the Jooq contributors including me if you want you can test it too :) but dont forget to review sqlite source code it is third party library that can be modified for other person outside Fermat or Linux OS ;)

Luis-Fernando-Molina commented 8 years ago

@sytolk would you like to build that new addon? I think it is interesting to have an alternative to the current Database addon we have. In this way we can let pluins devs to decide what to use.

Some extra requirements are:

a) the addon public interface must abstract the plugins from the underlying technology that is being used. b) the addon should restrict plugins only to access their own databases / files in the same way the current database addon does.

Regarding Fermat component ownership model, addons are to be owned only by the Foundation as they are very low level infrastructure. That means that we can set up a project with a bounty in fermats for whoever builts it for the foundation.

sytolk commented 8 years ago

@Luis-Fernando-Molina yes I can build this addon but I can only work for this in my free time.. but its appears that it will be not so much this week

Luis-Fernando-Molina commented 8 years ago

@jgpestana please create a bounty for this addon. @sytolk will provide you with the definition document when he finds time for that. Thank you.

jgpestana commented 8 years ago

@Luis-Fernando-Molina @sytolk Sure.

sytolk commented 8 years ago

@Luis-Fernando-Molina @furszy @lnacosta @acostarodrigo @darkestpriest @franklinmarcano1970 @Yayotron @jgpestana

I have receive Bounty template.pdf but I think that if I write some example project that will tell more.

https://github.com/sytolk/db-example

fermat-db-node-plugin-example is written for the Linux Server but this example (with different dependencies) can be written for Android too. You can review code and if you think that this project does not cover any of the plugin requirements let me know ? I also think that this project is very different from Fermat it use not only JOOQ but Spring framework -dependency injection do you have any experience or want to develop in this direction?