[Dhis2-devs] Performance in loading data entry

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…

···

2010/6/2 Ola Hodne Titlestad olatitle@gmail.com

2010/6/1 Lars Helge Øverland larshelge@gmail.com

Ola

Lars


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

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...

I think that's an important restriction if we are ever to consider
generating xforms from our datasets. The calculated data element
value would most likely be bound to an xforms:output control rather
than an xforms:input control but the value itself would have to be
part of the model which would presumably be generated off a dataset.

I'll do an example of this using xsltforms later but I've got some
stuff to finish first.

Cheers
Bob

···

2010/6/2 Lars Helge Øverland <larshelge@gmail.com>:

2010/6/2 Ola Hodne Titlestad <olatitle@gmail.com>

2010/6/1 Lars Helge Øverland <larshelge@gmail.com>

Ola
--------

Lars
_______________________________________________
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