← Back to team overview

dhis2-devs team mailing list archive

Re: Performance in loading data entry

 

2010/6/2 Ola Hodne Titlestad <olatitle@xxxxxxxxx>

> 2010/6/1 Lars Helge Øverland <larshelge@xxxxxxxxx>
>
>>
>> Hi,
>>
>> we are doing some observations on the Indian production servers and we see
>> that loading the data entry screens are quite slow.
>>
>> One cause to this is that we are loading each and every data element in
>> the custom data entry forms individually. I was trying to improve this by
>> doing a query and loading all data elements in the data set (corresponding
>> to the CDE).
>>
>
> Just to be 100% sure on this. CDE in this case means Custom Data Entry
> right? I've seen it used for Calculated Data Elements as well, which is
> confusing.
>
> Okay sorry I was referring to custom data entryscreen.


>
>
>> Then I suddenly learned that when designing CDEs one is not restricted to
>> the data elements in the data set the CDE is based on only, and that the
>> CDEs in the Sierra Leone database from last year contains data elements from
>> outside its data set.
>>
>> I think you are limited to data elements in one data set when designing,
> but is not controlled an kept consistent over time, e.g. when data elements
> move to another data set.
>
>
>> I find this quite weird and I think we should stop allowing this, in order
>> to get a quite significant and needed performance improvements. This change
>> will be compatible with the change of the data entry stuff we are working
>> on. But I don't know the consequences, ie. how many CDEs do we have around
>> which will be affected by this? Comments?
>>
>>
> Totally agree that a data entry form should be limited to the data elements
> in the corresponding data set, that is the point of the model.
> After all to open a new custom form you have to pick one dataset first, so
> it is from the UI quite obvious that a forms belongs to one dataset. The
> data element pop-up in the FcK editor only lists the data elements from the
> current dataset right? I am quite sure of that. What might have happened is
> that some data elements that where originally in Dataset A and used in Form
> A was later moved to data set B without being moved from Form A. It should
> of course not be allowed to remove a data element from a dataset if it is
> already used in the corresponding custom form. Or at least then it should be
> removed from the form (but that might be too confusing), so better to ask
> the user to remove it from the form first and then try again.
>
> There are definitely not any data forms in Sierra Leone for 2010 that has
> data elements from more than one data set (and that data set is the one that
> has the custom form), so I see no problem of being a bit more strict in
> reinforcing this rule.
>
>
Okay. Thanks for the info. We will change this for 2.0.5 then. Users with
custom data entry screens containing data elements not from the belonging
data sets are hereby warned...



> Ola
> --------
>
>
>
>
>> Lars
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~dhis2-devs<https://launchpad.net/%7Edhis2-devs>
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>

Follow ups

References