dhis2-devs team mailing list archive

[Murodullo Latifov <murodlatifov@xxxxxxxxx>]

'easy help access' needs further work by manual writers. First we need to test it and then manual writers should add tags and translation strings accordingly. 'dataelement history' also needs causion, it has dependency which is not in maven2 repository at this time. I will commit, you can revert in case, is this ok?


Frankly I don't think we should add dependencies that are not in the central maven repo. It makes it harder for other developers. We could set up our own / use the one on hisp.info, but this server has not been stable at all lately andit feels better to only be dependent on the central one.

Also, I have had some second thoughts about this solution... Isn't it a little overkill to change the persistence framework to accomplish this task? I agree that we should not reinvent the wheel and so on but in this case it seems just a matter of creating a DataValueModification object (or similar) and make add- and getall- functions. 

Also, this makes us dependent on Hibernate. We have seen talk of switching the persistence layer. In that case this function must be re-implemented. If we put it in the service layer it will remain.

Not saying I have the answer, just a little sceptical, what do you think?

Hi Lars,

We have many threads talking on easy installation, maintenance, porting to different environments, etc. What is the rational to move out of hibernate? Hibernate provides complete control and maintenance of underlying database. Can you imagine if someone in the field installs DHIS2 or upgrades and there are database schema changes? I don't think he will succeed if we are not using hibernate. iBATIS does not this, JPA does not, moreover they are database dependent, especially iBATIs. If we decide to go iBATIS, it is not good idea, than it becomes type of javascript, kill bug for mySql, kill bug for Postgress, H2, H3, H365. Here is some research done: http://seasar.javaeye.com/blog/233951. 

Sorry that I am talking to much but to honest we should make decisions that give long term solutions. Spring (AOP, DI, Security), Hibernate, MySQL, Struts2 or Spring MVC are well integrated, tons of documwentations. I am SQL and SP guy, but still feel hibernate is perfect solution for DHIS2 context. We have very few experts in the field and maintenance becomes a bottleneck if we don't use hibernate. We should learn and improve hibernate, make its performance faster.

Other thing I want to point here is use of @nnotations. If we manage to implement all this, we have to write POJOs, say @Entity, @Secured, @Audited and thats all. We have many blueprint marks, which fall into this category, type of general consideration, which IMHO should be discussed and decided in combination (Spring Hibernate, Spring Security...). 

I would call core developers to have skype discussion or actively participate into discussions before we come to make certain "general rules", which should be followed after and we don't face deadlocks (time spent for development, resources used). Like we have saying, make code Java1.5 compliant, this is known and all follow it. And if we decided to move out of hibernate for some reason, we should state that, by the same means as java1.5, remove such dependencies from pom and thats it. 

Its bad that I am sometimes on and off depending on my research needs, I might have missed some points made by others earlier, please correct me if I am wrong.

regards,
murod