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 > > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
