dhis2-users team mailing list archive

[Lars Helge Øverland <lars@xxxxxxxxx>]

On Mon, May 23, 2016 at 11:49 AM, Lars Helge Øverland <lars@xxxxxxxxx>
wrote:

> Hi Vanya,
>
> thanks for raising this issue - it's a good question. Having program
> indicators based on a data element / attributes dates instead of event date
> has come up earlier and something we will have to support.
>
> Short story: Currently this is not possible.
>
> Long story: The current event analytics solution has a compromise between
> query performance and flexibility around dates. If you have a look at the
> event analytics tables (e.g. "analytics_event_2015_ebayegv0exc") you will
> see two things:
>
> - The tables are partitioned by year (one analytics table with events per
> year per program) based on event date. This reduces query time since the
> indexes and tables become smaller instead of growing longer infinitely as
> times goes.
>
> - The tables have columns for all period types based on event date. This
> makes it possible to aggregate all periods in a query through group-bys on
> those columns, instead of having to do one query per period, and hence
> improves performance a lot.
>
> All this is great for performance but limits the analysis to be based on
> event date. To partition data one needs a partition key and event date is
> pretty much the only suitable candidate (in addition to program).
>
> So to support aggregation / analytics based on any date from data
> elements/attributes of the events, one must sacrifice some of this and
> basically have one analytics table per program, and have one query per
> aggregation period. This will soon be a very popular requirement so we will
> have to support it - still pondering how to solve this in a way which
> offers required performance and flexibility.
>
>
> best regards,
>
> Lars
>
>
I have created a blueprint for this here:

https://blueprints.launchpad.net/dhis2/+spec/event-analytics-date-flexibility



Lars