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