Re: [Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1785: Audit trail logging functions for DataSet, OrganisationUnit, User modules.

2010-04-19 Thread Bob Jolliffe
Hi Viet

On 19 April 2010 13:47, Viet Nguyen  wrote:
>
>
> On Mon, Apr 19, 2010 at 5:51 PM, Bob Jolliffe  wrote:
>>
>> Hi Viet
>>
>> This is excellent.
>>
>> When we first started discussing using logging framework for audit you
>> pointed out that logging is most commonly used for system
>> info/diagnostics/debugging.  Which is true.  Of course logging works
>> pretty well for audit as well, but I was thinking (influenced by
>> http://www.mail-archive.com/gene...@logging.apache.org/msg00747.html)
>> that it makes sense to use a distinct logger, rather than one based
>> after the class name, for this.
>>
>> So for example instead of where you have:
>> private Logger logger = Logger.getLogger( getClass() );
>>
>> I was thinking something more like
>> private Logger audit_logger = Logger.getLogger( AUDIT_LOG ); // where
>> AUDIT_LOG is a globally accessible string
>>
>> Or considering that the audit_logger could be thought of as a
>> singleton throughout the system, just use a setter and configure by
>> spring.  Or a static getLogger method on a simple AuditLogger class.
>>
>> However, I see you have extended Level to produce a new AUDIT_LEVEL
>> and routed that to a distinct log appender which I can see also works
>> well to manage the output of logging in a discriminatory way.  That's
>> pretty cool.  I'm still in two minds whether the enabling of audit
>> should be related to the debug level you want to have on diagnostics
>> though.  I might reasonably want to turn audit off and debug on for
>> example.  For which I'd want a distinct audit logger.  Maybe that's
>> not reasonable.
>>
>> What do you think?
>>
>> Cheers
>> Bob
>
>
> For your first concern, I think using AOP can solve it. Lars also told me
> about that.
> I will try to apply AOP to this.
>
> About distinct audit logger, I don't know how to use two different loggers
> in one application... Unless I manually create a logger class ( create file,
> write logging message to that fileetc.. ) which I did before in my old
> project...

I am no expert on log4j but it seems that fortunately it's not as
complicated as you expect.  And you are already using a great many
different loggers in one application!.  Its just that each one is is
typically named after the class in which it is used.  That is the
normal and natural way to configure logging for diagnostics.  And all
these named loggers form themselves into a hierarchical tree on top of
the root logger.  So typically we have many loggers with names like:

"org.hisp.dhis.dataset.DefaultDataSetService",
"org.hisp.dhis.importexport.DefaultDhis14XMLImportService" etc

The nice thing about this is that one can use the inheritance in the
tree to fine tune what goes on in branches of the tree.  So for
example I should be able to set logging level to DEBUG for all loggers
below org.hisp.dhis.importexport.

So having loggers in a tree is cool, but what is also cool is that you
can structure that tree using whichever strings are appropriate.  For
diagnostic purposes it is generally structured according to
class/package names.  But you can equally have loggers called
"security.audit", "security.alarm" or "security.core.audit" and
"security.web.audit" etc,  There is no difference in the code.  And
the log4j properties will work as before except that you can
(optionally) override the root logger if you want to configure the
security logs separately from the diagnostic system logs.

Anyway I agree that its really not critical and the really good thing
is that you have implemented the audit logging.  I guess I'm just
trying to set your mind at rest that you might not think you know how
to work with multiple loggers but in fact you do.

If at some stage in the future we want to separate the audit logger
from the rest it will be simple.  If we do that I would be tempted to
bring the audit levels and audit utils stuff together into an AuditLog
class.

Cheers
Bob

BTW I am not meaning to be critical.  At least it shows I looked at the code :-)

>
> Anyway...turning debug on and audit offis not really a common use I
> think ... I always want to see everything when I turn debug on ...
> And when you are debugging , means that you don't work on production server,
> so it will not effect the production logging files...
> However, I will google more about using two different loggers  in one
> application, should be interesting.
>
> Anyway ...I have to back with STQC bugs now ...so could we consider that
> committed code as a beta version of this audit trail logging ...
>
>>
>> On 19 April 2010 10:56,   wrote:
>> > 
>> > revno: 1785
>> > committer: Viet 
>> > branch nick: trunk
>> > timestamp: Mon 2010-04-19 16:54:45 +0700
>> > message:
>> >  Audit trail logging functions for DataSet, OrganisationUnit, User
>> > modules.
>> > added:
>> >
>> >  dhis-2/dhis-support/dhis-support-system/src/main/java/org/hisp/dhis/system/util/AuditLogLevel.java
>> >
>> >  dhis-

Re: [Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1785: Audit trail logging functions for DataSet, OrganisationUnit, User modules.

2010-04-19 Thread Jo Størset

Den 19. apr. 2010 kl. 18.17 skrev Viet Nguyen:

> About distinct audit logger, I don't know how to use two different loggers in 
> one application... Unless I manually create a logger class ( create file, 
> write logging message to that fileetc.. ) which I did before in my old 
> project...
> 
> Anyway...turning debug on and audit offis not really a common use I think 
> ... I always want to see everything when I turn debug on ...
> And when you are debugging , means that you don't work on production server, 
> so it will not effect the production logging files...
> However, I will google more about using two different loggers  in one 
> application, should be interesting.

All it takes is just having a separate name for the audit log, as Bob says.  If 
you want it to log to a separate file, you just configure a separate log4j log 
for that. But I agree with Bob, having an audit logger dependency injected, is 
better. After all, it is a business concern, and with an AuditLogger interface 
it will be trivial to change the implementation later, if that is required.

> Anyway ...I have to back with STQC bugs now ...so could we consider that 
> committed code as a beta version of this audit trail logging ...

That sounds about right :) Good to have audit logging, at least!

Jo

smime.p7s
Description: S/MIME cryptographic signature
___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1789: (GIS) CSS fix.

2010-04-19 Thread noreply

revno: 1789
committer: Jan Henrik Overland 
branch nick: gis
timestamp: Mon 2010-04-19 17:50:11 +0200
message:
  (GIS) CSS fix.
added:
  
dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/jsonminAggregatedMapValues.vm
modified:
  
dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/mapping/css/style.css


--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to 
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== added file 'dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/jsonminAggregatedMapValues.vm'
--- dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/jsonminAggregatedMapValues.vm	1970-01-01 00:00:00 +
+++ dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/jsonminAggregatedMapValues.vm	2010-04-19 15:50:11 +
@@ -0,0 +1,1 @@
+#set( $size = $object.size() ){"mapvalues":[#foreach( $value in $object ){"orgUnitId":"$!{value.organisationUnitId}","orgUnitName":"$!{value.organisationUnitName}","featureId":"$!{value.featureId}","value":"$!{value.value}"}#if( $velocityCount < $size ),#end#end]}
\ No newline at end of file

=== modified file 'dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/mapping/css/style.css'
--- dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/mapping/css/style.css	2010-04-14 19:04:47 +
+++ dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/mapping/css/style.css	2010-04-19 15:50:11 +
@@ -51,7 +51,11 @@
 	font-family:myriad pro,myriad web,arial,tahoma,helvetica;
 	font-weight:normal;
 }
-
+.loading-indicator {
+	font-size:10px;
+	color:#666;
+	padding-left:21px;
+}
 
 /* OpenLayers (include in lib)
 .olControlOverviewMapElement {

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1788: (GIS) Mapvalues json response minified.

2010-04-19 Thread noreply

revno: 1788
committer: Jan Henrik Overland 
branch nick: gis
timestamp: Mon 2010-04-19 17:34:23 +0200
message:
  (GIS) Mapvalues json response minified.
modified:
  dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml
  
dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/resources/mapfish/widgets/geostat/Choropleth.js


--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to 
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml'
--- dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml	2010-04-19 13:48:35 +
+++ dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml	2010-04-19 15:34:23 +
@@ -70,7 +70,7 @@
 		
 			
-/dhis-web-mapping/jsonAggregatedMapValues.vm
+/dhis-web-mapping/jsonminAggregatedMapValues.vm
 		
 
 		___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1787: (GIS) Reduced json filesize when assigning orgunits.

2010-04-19 Thread noreply

revno: 1787
committer: Jan Henrik Overland 
branch nick: trunk
timestamp: Mon 2010-04-19 15:48:35 +0200
message:
  (GIS) Reduced json filesize when assigning orgunits.
added:
  
dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/jsonminMapOrganisationUnitRelations.vm
  
dhis-2/dhis-web/dhis-web-mapping/src/main/webapp/dhis-web-mapping/jsonminOrganisationUnits.vm
modified:
  dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml


--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to 
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
=== modified file 'dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml'
--- dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml	2010-04-06 17:41:30 +
+++ dhis-2/dhis-web/dhis-web-mapping/src/main/resources/struts.xml	2010-04-19 13:48:35 +
@@ -35,7 +35,7 @@
 		
 			
-/dhis-web-mapping/jsonOrganisationUnits.vm
+/dhis-web-mapping/jsonminOrganisationUnits.vm
 		
 
 		
@@ -132,7 +132,7 @@
 		
 			
-/dhis-web-mapping/jsonMapOrganisationUnitRelations.vm
+/dhis-web-mapping/jsonminMapOrganisationUnitRelations.vm
 		
 
 		___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


Re: [Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1785: Audit trail logging functions for DataSet, OrganisationUnit, User modules.

2010-04-19 Thread Viet Nguyen
On Mon, Apr 19, 2010 at 5:51 PM, Bob Jolliffe  wrote:

> Hi Viet
>
> This is excellent.
>
> When we first started discussing using logging framework for audit you
> pointed out that logging is most commonly used for system
> info/diagnostics/debugging.  Which is true.  Of course logging works
> pretty well for audit as well, but I was thinking (influenced by
> http://www.mail-archive.com/gene...@logging.apache.org/msg00747.html)
> that it makes sense to use a distinct logger, rather than one based
> after the class name, for this.
>
> So for example instead of where you have:
> private Logger logger = Logger.getLogger( getClass() );
>
> I was thinking something more like
> private Logger audit_logger = Logger.getLogger( AUDIT_LOG ); // where
> AUDIT_LOG is a globally accessible string
>
> Or considering that the audit_logger could be thought of as a
> singleton throughout the system, just use a setter and configure by
> spring.  Or a static getLogger method on a simple AuditLogger class.
>
> However, I see you have extended Level to produce a new AUDIT_LEVEL
> and routed that to a distinct log appender which I can see also works
> well to manage the output of logging in a discriminatory way.  That's
> pretty cool.  I'm still in two minds whether the enabling of audit
> should be related to the debug level you want to have on diagnostics
> though.  I might reasonably want to turn audit off and debug on for
> example.  For which I'd want a distinct audit logger.  Maybe that's
> not reasonable.
>
> What do you think?
>
> Cheers
> Bob
>


For your first concern, I think using AOP can solve it. Lars also told me
about that.
I will try to apply AOP to this.

About distinct audit logger, I don't know how to use two different loggers
in one application... Unless I manually create a logger class ( create file,
write logging message to that fileetc.. ) which I did before in my old
project...

Anyway...turning debug on and audit offis not really a common use I
think ... I always want to see everything when I turn debug on ...
And when you are debugging , means that you don't work on production server,
so it will not effect the production logging files...
However, I will google more about using two different loggers  in one
application, should be interesting.

Anyway ...I have to back with STQC bugs now ...so could we consider that
committed code as a beta version of this audit trail logging ...


>
> On 19 April 2010 10:56,   wrote:
> > 
> > revno: 1785
> > committer: Viet 
> > branch nick: trunk
> > timestamp: Mon 2010-04-19 16:54:45 +0700
> > message:
> >  Audit trail logging functions for DataSet, OrganisationUnit, User
> modules.
> > added:
> >
>  
> dhis-2/dhis-support/dhis-support-system/src/main/java/org/hisp/dhis/system/util/AuditLogLevel.java
> >
>  
> dhis-2/dhis-support/dhis-support-system/src/main/java/org/hisp/dhis/system/util/AuditLogUtil.java
> > modified:
> >
>  
> dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataset/DefaultDataSetService.java
> >
>  
> dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/organisationunit/DefaultOrganisationUnitService.java
> >
>  
> dhis-2/dhis-services/dhis-service-core/src/main/resources/META-INF/dhis/beans.xml
> >
>  
> dhis-2/dhis-services/dhis-service-patient/src/main/java/org/hisp/dhis/patient/DefaultPatientService.java
> >
>  
> dhis-2/dhis-services/dhis-service-patient/src/main/resources/META-INF/dhis/beans.xml
> >
>  
> dhis-2/dhis-services/dhis-service-user-hibernate/src/main/java/org/hisp/dhis/user/hibernate/HibernateUserStore.java
> >
>  
> dhis-2/dhis-services/dhis-service-user-hibernate/src/main/resources/META-INF/dhis/beans.xml
> >
>  
> dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/WEB-INF/classes/log4j.properties
> >
>  
> dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/util/validate/additional-methods.js
> >
>  
> dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/util/validate/jquery.validate.js
> >
>  
> dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-dataset/src/main/webapp/dhis-web-maintenance-dataset/addSection.vm
> >
>  
> dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-organisationunit/src/main/webapp/dhis-web-maintenance-organisationunit/addOrganisationUnitGroupSetForm.vm
> >
>  
> dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-organisationunit/src/main/webapp/dhis-web-maintenance-organisationunit/updateOrganisationUnitGroupSetForm.vm
> >
>  
> dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-patient/src/main/java/org/hisp/dhis/patient/action/patient/AddPatientAction.java
> >
>  
> dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-patient/src/main/java/org/hisp/dhis/patient/action/patient/ValidatePatientAction.java
> > The size of the diff (1144 lines) is larger than your specified limit of
> 1000 lines
> >
> > --
> > lp:dhis2

Re: [Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1785: Audit trail logging functions for DataSet, OrganisationUnit, User modules.

2010-04-19 Thread Bob Jolliffe
Hi Viet

This is excellent.

When we first started discussing using logging framework for audit you
pointed out that logging is most commonly used for system
info/diagnostics/debugging.  Which is true.  Of course logging works
pretty well for audit as well, but I was thinking (influenced by
http://www.mail-archive.com/gene...@logging.apache.org/msg00747.html)
that it makes sense to use a distinct logger, rather than one based
after the class name, for this.

So for example instead of where you have:
private Logger logger = Logger.getLogger( getClass() );

I was thinking something more like
private Logger audit_logger = Logger.getLogger( AUDIT_LOG ); // where
AUDIT_LOG is a globally accessible string

Or considering that the audit_logger could be thought of as a
singleton throughout the system, just use a setter and configure by
spring.  Or a static getLogger method on a simple AuditLogger class.

However, I see you have extended Level to produce a new AUDIT_LEVEL
and routed that to a distinct log appender which I can see also works
well to manage the output of logging in a discriminatory way.  That's
pretty cool.  I'm still in two minds whether the enabling of audit
should be related to the debug level you want to have on diagnostics
though.  I might reasonably want to turn audit off and debug on for
example.  For which I'd want a distinct audit logger.  Maybe that's
not reasonable.

What do you think?

Cheers
Bob

On 19 April 2010 10:56,   wrote:
> 
> revno: 1785
> committer: Viet 
> branch nick: trunk
> timestamp: Mon 2010-04-19 16:54:45 +0700
> message:
>  Audit trail logging functions for DataSet, OrganisationUnit, User modules.
> added:
>  dhis-2/dhis-support/dhis-support-system/src/main/java/org/hisp/dhis/system/util/AuditLogLevel.java
>  dhis-2/dhis-support/dhis-support-system/src/main/java/org/hisp/dhis/system/util/AuditLogUtil.java
> modified:
>  dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataset/DefaultDataSetService.java
>  dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/organisationunit/DefaultOrganisationUnitService.java
>  dhis-2/dhis-services/dhis-service-core/src/main/resources/META-INF/dhis/beans.xml
>  dhis-2/dhis-services/dhis-service-patient/src/main/java/org/hisp/dhis/patient/DefaultPatientService.java
>  dhis-2/dhis-services/dhis-service-patient/src/main/resources/META-INF/dhis/beans.xml
>  dhis-2/dhis-services/dhis-service-user-hibernate/src/main/java/org/hisp/dhis/user/hibernate/HibernateUserStore.java
>  dhis-2/dhis-services/dhis-service-user-hibernate/src/main/resources/META-INF/dhis/beans.xml
>  dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/WEB-INF/classes/log4j.properties
>  dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/util/validate/additional-methods.js
>  dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/util/validate/jquery.validate.js
>  dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-dataset/src/main/webapp/dhis-web-maintenance-dataset/addSection.vm
>  dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-organisationunit/src/main/webapp/dhis-web-maintenance-organisationunit/addOrganisationUnitGroupSetForm.vm
>  dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-organisationunit/src/main/webapp/dhis-web-maintenance-organisationunit/updateOrganisationUnitGroupSetForm.vm
>  dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-patient/src/main/java/org/hisp/dhis/patient/action/patient/AddPatientAction.java
>  dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-patient/src/main/java/org/hisp/dhis/patient/action/patient/ValidatePatientAction.java
> The size of the diff (1144 lines) is larger than your specified limit of 1000 
> lines
>
> --
> lp:dhis2
> https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk
>
> Your team DHIS 2 developers is subscribed to branch lp:dhis2.
> To unsubscribe from this branch go to 
> https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription
>
> ___
> Mailing list: https://launchpad.net/~dhis2-devs
> Post to     : dhis2-devs@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~dhis2-devs
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] Hudson build became unstable: Dhis2 Service Trunk #608

2010-04-19 Thread support
See 



___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] Hudson build became unstable: Dhis2 Ser vice Trunk » DHIS Aggregation Service - Default #608

2010-04-19 Thread support
See 




___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] Hudson build became unstable: Dhis2 Ser vice Trunk » DHIS Core API Implementations #608

2010-04-19 Thread support
See 




___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] [Branch ~dhis2-devs-core/dhis2/trunk] Rev 1785: Audit trail logging functions for DataSet, OrganisationUnit, User modules.

2010-04-19 Thread noreply

revno: 1785
committer: Viet 
branch nick: trunk
timestamp: Mon 2010-04-19 16:54:45 +0700
message:
  Audit trail logging functions for DataSet, OrganisationUnit, User modules. 
added:
  
dhis-2/dhis-support/dhis-support-system/src/main/java/org/hisp/dhis/system/util/AuditLogLevel.java
  
dhis-2/dhis-support/dhis-support-system/src/main/java/org/hisp/dhis/system/util/AuditLogUtil.java
modified:
  
dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataset/DefaultDataSetService.java
  
dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/organisationunit/DefaultOrganisationUnitService.java
  
dhis-2/dhis-services/dhis-service-core/src/main/resources/META-INF/dhis/beans.xml
  
dhis-2/dhis-services/dhis-service-patient/src/main/java/org/hisp/dhis/patient/DefaultPatientService.java
  
dhis-2/dhis-services/dhis-service-patient/src/main/resources/META-INF/dhis/beans.xml
  
dhis-2/dhis-services/dhis-service-user-hibernate/src/main/java/org/hisp/dhis/user/hibernate/HibernateUserStore.java
  
dhis-2/dhis-services/dhis-service-user-hibernate/src/main/resources/META-INF/dhis/beans.xml
  
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/WEB-INF/classes/log4j.properties
  
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/util/validate/additional-methods.js
  
dhis-2/dhis-web/dhis-web-commons-resources/src/main/webapp/dhis-web-commons/util/validate/jquery.validate.js
  
dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-dataset/src/main/webapp/dhis-web-maintenance-dataset/addSection.vm
  
dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-organisationunit/src/main/webapp/dhis-web-maintenance-organisationunit/addOrganisationUnitGroupSetForm.vm
  
dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-organisationunit/src/main/webapp/dhis-web-maintenance-organisationunit/updateOrganisationUnitGroupSetForm.vm
  
dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-patient/src/main/java/org/hisp/dhis/patient/action/patient/AddPatientAction.java
  
dhis-2/dhis-web/dhis-web-maintenance/dhis-web-maintenance-patient/src/main/java/org/hisp/dhis/patient/action/patient/ValidatePatientAction.java
The size of the diff (1144 lines) is larger than your specified limit of 1000 
lines

--
lp:dhis2
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk

Your team DHIS 2 developers is subscribed to branch lp:dhis2.
To unsubscribe from this branch go to 
https://code.launchpad.net/~dhis2-devs-core/dhis2/trunk/+edit-subscription

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp


[Dhis2-devs] Question on aggregation periods

2010-04-19 Thread Jason Pickering
Hi Lars,
I have been looking at the aggregation process and have a few questions.

I chose a range of months (January-December 2009) and aggregated all
data from facilities to districts. Monitoring the logs, I saw that a
greater number of periods were aggregated during the process for some
reason, which seemed strange to me. I dug deeper and pulled out the
resulting set of periods [1]. As you can see, there are a number of
periods, that overlap, but which are not contained in any of the
requested aggregation periods. [2]

First, it would seem that DHIS2 is asking for all data that "overlaps"
the desired range of time periods, but actually, it should be the time
periods requested, and any time periods that the desired aggregation
time periods are composed of.  For instance I have a quarterly time
period with periodid 20684. This query gives me a list of all periods
that this period may be composed of

SELECT periodid from period where startdate >= (SELECT startdate from
period where periodid = 20684)
and  enddate <= (SELECT enddate from period where periodid = 20684)
and  periodid <> 20684

So, I would expect that the aggregation engine would analyze the
requested time periods and data elements, and then decompose those
individually via a query such as given above, to get all "dependent"
time periods. This process would repeat itself until the time periods
could not be decomposed any further or until it does not make sense to
do so. I would expect that for the indicators/data elements chosen by
the user, that only the periodicity of the data set would be used to
determine the base time period which to begin aggregation. For
instance, I might chose to aggregate data which has been entered with
a monthly periodicity, and aggregate it to quarters. The aggregation
engine should know that based on my choice of data elements (e.g.
monthly) that all periods for that given indicator/data element need
to be retrieved and then aggregated into the destination time period.

Could you maybe comment on why this happens this way? It would seem to
be wasteful, as one of the most limiting steps in terms of
performance, seems to be related to input/output of the data. If we
can decrease this, it should speed things up a bit.

Regards,
Jason


[1] http://pastebin.com/XAEtCdzY
[2] http://pastebin.com/uFMgcxtT
-- 
--
Jason P. Pickering
email: jason.p.picker...@gmail.com
tel:+260968395190

___
Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp