Hi Morten, Pardon ! I am just coming from office after doing about 9 hours of hard work like other DHIS2 implementer s in more than 30 countries. I am not sure you are talking about which Quick-Fix !!! The Quick-fix with revision number 9242 or 9323 !!! We are not getting exactly ! Could you let us know which one exactly !
If you means you did pretty cool commit and quick-fix with revision 9323 at airport than where you did pretty cool commit with revision 9242 !!! With kind Regards, Brajesh On Tue, Dec 18, 2012 at 7:39 PM, Morten Olav Hansen <[email protected]>wrote: > This was just a quick-fix done at the airport. I will look at it later. > > -- > Morten > > > > On Mon, Dec 17, 2012 at 7:13 PM, Brajesh Murari > <[email protected]>wrote: > >> Hi Morten, >> >> Pardon to put you in little bit more work around, although my build >> process is working fine in my local system ...I have three quires which i >> want to share with you and others on list before I lose them... >> >> 1. I just want to know which one is the best !!! >> >> public class OrganisationUnitByLevelComparator >> implements Comparator<OrganisationUnit> >> { >> @Override >> public int compare( OrganisationUnit o1, OrganisationUnit o2 ) >> { >> return *new Integer*( o1.getOrganisationUnitLevel() ).compareTo( >> o2.getOrganisationUnitLevel() ); >> } >> } >> >> Note: In each comparison, creating a new wrapper Integer object, ie. if >> this could be called approx 40,000 times to compare two different >> Organisation Units might be more in some case ( they might be name of >> households of a certain West African country ) while loading a Tree than >> creating 40,000 new wrapper Integer objects just for doing comparison, and >> that might be treated as bottle neck in such large scale operation as an >> assumption. >> >> *or * >> * >> * >> Light weighted code like given below >> >> public class OrganisationUnitByLevelComparator >> implements Comparator<OrganisationUnit> >> { >> @Override >> public int compare( OrganisationUnit o1, OrganisationUnit o2 ) >> { >> return o1.getOrgaonisationUnitLevel() - >> o2.getOrganisationUnitLevel(); >> } >> } >> >> >> 2. Would you like to review your commit in revision 9329 !!! >> >> 3. Are you in a favor to configure Crucible with DHIS2 root trunk like >> other tools eg. CI (Jinkins/Atlassian Bamboo etc..) so that other can >> put their code review comments on dhis2 committed code by great commiter >> like you !!! >> >> http://www.atlassian.com/software/crucible/overview >> >> If yes in second and third query, than i am strongly recommend, just do >> it in DHIS2 before December 24th this year. >> >> Regards, >> ~Brajesh~ >> >> >> On Sun, Dec 16, 2012 at 1:33 AM, Morten Olav Hansen >> <[email protected]>wrote: >> >>> Ok >>> On Dec 15, 2012 10:12 PM, "Brajesh Murari" <[email protected]> >>> wrote: >>> >>>> Hi Morten, >>>> >>>> I am using java version with info below >>>> >>>> brajesh.murari@mohlapbrajesh /cygdrive/d/src/dhis2/dhis-2 >>>> $ java -version >>>> java version "1.6.0_26" >>>> Java(TM) SE Runtime Environment (build 1.6.0_26-b03) >>>> Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode) >>>> >>>> After your fix, its now working, with same above java version. If >>>> you do any >>>> java version up-gradation in scm-dhis2, don't forget to update its info >>>> here as well on >>>> >>>> http://www.dhis2.org/development >>>> >>>> I will upgrade my java version on 24th December in morning at 7:30 AM >>>> IST after >>>> taking fresh shower with cold/child water. I thought, may be there >>>> would be any real time idea implementation with your commit 9242 without >>>> blueprint or any bug fixing after Bob's universal declaration ie. "Been >>>> looking at the case of a certain West African country with *40000 >>>> orgunits*. *Which is actually not a huge number of objects and we >>>> could very likely be looking at orgunit tables bigger than this as villages >>>> and even households start finding their way into the tree*." >>>> >>>> On Sat, Dec 15, 2012 at 10:58 PM, Morten Olav Hansen < >>>> [email protected]> wrote: >>>> >>>>> If you have an old version of Java, the commit I just did should >>>>> probably fix it. But I would suggest that you upgrade. >>>>> >>>>> -- >>>>> Morten >>>>> >>>>> >>>>> >>>>> On Sat, Dec 15, 2012 at 8:12 PM, Morten Olav Hansen < >>>>> [email protected]> wrote: >>>>> >>>>>> There should not be any issues with that code, and as bob said our ci >>>>>> server seems to compile it fine (also, no other dev has complained) . >>>>>> Update, clean, install and if it fails update java. >>>>>> >>>>> *>>>*Developers usually don't take fresh checkout nor they like to do >>>> some crazy white box testing all the time, that's why perhaps they may >>>> not complain usually, but there are some developers who don't even >>>> relay on CI nightly build status update, that's why they complain >>>> about build failure...which was perhaps true. >>>> *:-)* >>>> >>>> >>>>> On Dec 15, 2012 2:50 AM, "Bob Jolliffe" <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Brajesh I am not sure I understand the tone of your email nor the >>>>>>> impressive cc list. But anyway ... >>>>>>> >>>>>>> If you have a build failure then please describe that simply on the >>>>>>> list and perhaps people can help you. It is worth noting that the >>>>>>> continuous integration server http://apps.dhis2.org/ci/ is building >>>>>>> fine so at least the current trunk is fine. >>>>>>> >>>>>>> In general if there was a compilation failure on trunk (and I am not >>>>>>> sure I can verify because I don't think I built 9242 but you can look >>>>>>> back >>>>>>> through the emails and see) an alert is sent to the devs list and it is >>>>>>> resolved very quickly. Never more than a few hours. So I think you are >>>>>>> safe regarding the issue being resolved before December 24. >>>>>>> >>>>>>> Please verify that you have updated to latest trunk and see if the >>>>>>> problem persists. If so then give a detailed report to the list. But >>>>>>> please do so in a separate thread. >>>>>>> >>>>>>> Regards >>>>>>> Bob >>>>>>> >>>>>>> >>>>>>> On 14 December 2012 21:31, Brajesh Murari >>>>>>> <[email protected]>wrote: >>>>>>> >>>>>>>> Hello Bob, >>>>>>>> >>>>>>>> Wishing you and everyone on dhis2-dev list, a >>>>>>>> joyous Christmas season. >>>>>>>> >>>>>>>> I am getting build failure in main trunk build with info as given >>>>>>>> below, >>>>>>>> >>>>>>>> [INFO] ------------------------------------------------------------- >>>>>>>> [ERROR] COMPILATION ERROR : >>>>>>>> [INFO] ------------------------------------------------------------- >>>>>>>> [ERROR] >>>>>>>> \src\dhis2\dhis-2\dhis-api\src\main\java\org\hisp\dhis\organisationunit\comparator\OrganisationUnitByLevelComparator.java:[43,22] >>>>>>>> cannot find symbol >>>>>>>> symbol : method compare(int,int) >>>>>>>> location: class java.lang.Integer >>>>>>>> [INFO] 1 error >>>>>>>> >>>>>>>> On Sat, Dec 8, 2012 at 9:45 PM, Bob Jolliffe <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> Just sharing some thoughts before I lose them ... >>>>>>>>> >>>>>>>>> Been looking at the case of a certain West African country >>>>>>>>> with 40000 orgunits. Which is actually not a huge number of objects >>>>>>>>> and >>>>>>>>> we could very likely be looking at orgunit tables bigger than this as >>>>>>>>> villages and even households start finding their way into the tree. >>>>>>>>> >>>>>>>>> >>>>>>>> One day later after your this email, Morten Olav Hansen did >>>>>>>> a miner change >>>>>>>> in one custom comparator ie. >>>>>>>> OrganisationUnitByLevelComparator.java<http://bazaar.launchpad.net/~dhis2-devs-core/dhis2/trunk/revision/9242/dhis-2/dhis-api/src/main/java/org/hisp/dhis/organisationunit/comparator/OrganisationUnitByLevelComparator.java> >>>>>>>> . >>>>>>>> in lp:dhis2 branch with revision number 9242. Before 9242, this >>>>>>>> comparator >>>>>>>> was looks like this given below >>>>>>>> >>>>>>>> @Override >>>>>>>> public int compare( OrganisationUnit o1, OrganisationUnit o2 ){ >>>>>>>> return o1.getLevel() - o2.getLevel(); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> Now, after 9242, it has been like >>>>>>>> >>>>>>>> @Override >>>>>>>> public int compare( OrganisationUnit o1, OrganisationUnit o2 ){ >>>>>>>> return Integer.compare( o1.getOrganisationUnitLevel(), >>>>>>>> o2.getOrganisationUnitLevel() ); >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> After doing this change, committer left a log as "Updated >>>>>>>> OrgUnitByLevelComparator to not rely on pre-populated level field, >>>>>>>> Added >>>>>>>> 'level Sorted' parameter to OrgUnitController, set to true if you want >>>>>>>> orgUnits sored by level". Could you let us know why >>>>>>>> this pretty change results with DHIS2 build failure !!! I am not sure >>>>>>>> but >>>>>>>> is there any link in between pretty cool commit 9242 and your this >>>>>>>> email >>>>>>>> !!! Pls elaborate and provide us your expert view on this issue, i am >>>>>>>> expecting, we should do pretty cool hand around this issue and you let >>>>>>>> us >>>>>>>> know how we should comes out from this >>>>>>>> "Build Failure" !!! I wish this issue should be closed before 23rd >>>>>>>> December. >>>>>>>> >>>>>>>> Our orgunit tree (the one-true-tree) is maintained using parentid >>>>>>>>> pointers. This is simple enough to maintain and updates and >>>>>>>>> insertions are >>>>>>>>> efficient. >>>>>>>>> >>>>>>>>> Of course updates and insertions are relatively rare. What we >>>>>>>>> need to do much more frequently is selecting various subtrees. All >>>>>>>>> the >>>>>>>>> facilities in a district, all the districts in a province etc. >>>>>>>>> >>>>>>>>> Also the depth of our trees are relatively shallow. Most places >>>>>>>>> seem to have around 5 levels. There is some trend that this starts to >>>>>>>>> increase, but not exponentially. We might conceive one day of 8 or >>>>>>>>> even 10 >>>>>>>>> levels but not 100s or 1000s of levels. Its this shallowness which >>>>>>>>> makes >>>>>>>>> the _orgunitstructure table viable as the number of columns in that >>>>>>>>> table >>>>>>>>> will always be within a practical limit.. >>>>>>>>> >>>>>>>>> Selecting for tree structures (traversal) which are built using >>>>>>>>> 'parentid' is not very efficient. Postgres offers 'WITH RECURSIVE' >>>>>>>>> which >>>>>>>>> is pretty cool if you can get your head around it, but not supported >>>>>>>>> in >>>>>>>>> mysql (and not necessarily fast either). >>>>>>>>> >>>>>>>>> So when selecting subtrees the _orgunitstructure table is our best >>>>>>>>> friend. I use it for the mydatamart aggregatedXXvalue queries and it >>>>>>>>> looks >>>>>>>>> like Lars uses it in the scheduled datamart job as well as well. >>>>>>>>> And it >>>>>>>>> is the obvious table to use when implementing filtering as I am now >>>>>>>>> looking >>>>>>>>> at re mydatamart export. >>>>>>>>> >>>>>>>>> The problem is (with this and the other resource tables) how to >>>>>>>>> maintain integrity. Currently we generate this table on demand (from >>>>>>>>> the >>>>>>>>> user) from the parentid pointers. If users forget to do it then all >>>>>>>>> sorts >>>>>>>>> of things fail. There has been some discussion on list of generating >>>>>>>>> this, >>>>>>>>> at least nightly which would be an improvement. There would be some >>>>>>>>> benefit in maintaining it dynamically, ie "triggered" during those >>>>>>>>> relatively rare updates and insertions of new orgunits. One possible >>>>>>>>> consequence of this approach would be that the parentid on the orgunit >>>>>>>>> becomes effectively redundant. It could be argued that its *only* >>>>>>>>> current >>>>>>>>> use is to generate the _orgunitstructure table. >>>>>>>>> >>>>>>>>> A consequence of the parentid being redundant is that hierarchy is >>>>>>>>> maintained in a separate table to the orgunits themselves. And there >>>>>>>>> is no >>>>>>>>> reason why there should be only one _orgunitstructure table. There >>>>>>>>> could >>>>>>>>> be any number, limited only by the number of hierarchies we needed to >>>>>>>>> maintain. There's a thought ... >>>>>>>>> >>>>>>>>> Of course the other use for the parentid is when you are exporting >>>>>>>>> a bundle of orgunits in a way which reflects the (or a) hierarchy. In >>>>>>>>> which case it is really kind to clients to serialize this tree as a >>>>>>>>> breadth-first traversal ie. they come out in order which is quick and >>>>>>>>> easy >>>>>>>>> to rebuild on the client. That is what I am looking at doing now to >>>>>>>>> try >>>>>>>>> and help out our mydatamart metadata export. And I will of course >>>>>>>>> use the >>>>>>>>> _orgunitstructure table to make this trivial on the server side. >>>>>>>>> >>>>>>>>> But some principles derived from the above discussion: >>>>>>>>> 1. try to avoid using parentid directly in code ... always link >>>>>>>>> to the orgunitstructuretable. This might ease its eventual demise >>>>>>>>> 2. all places where we export collections of orgunits should be >>>>>>>>> in a proper traversal - breadth first or depth firt shouldn't matter >>>>>>>>> really but I'm going to do the latter. >>>>>>>>> >>>>>>>>> Bob >>>>>>>>> >>>>>>>> >>>>>>>> Merry Christmas >>>>>>>> :-) >>>>>>>> >>>>>>>> Regards, >>>>>>>> Brajesh >>>>>>>> -- >>>>>>>> >>>>>>> >>>> Any way, build procedure is working fine now in my system. >>>> thanks for informing us. >>>> :-) >>>> >>>> -- >>>> Regards, >>>> Brajesh >>>> >>>> >>>> >> >> >> -- >> Regards, >> Brajesh >> >> >> > -- Regards, Brajesh
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
