[Branch ~dhis2-devs-core/dhis2/trunk] Rev 938: Made the uniqueness constraint on CategoryOption back in. Will maintain it in a transition period.

DHIS_2_Users · 30 October 2009 13:24

jason · 30 October 2009 13:43

Could some one remind me once again what the point of having a
category option in two separate categories is? is there a use case
here? It does not seem totally obvious, but maybe I am missing
something.

Regards,
jason

···

On Fri, Oct 30, 2009 at 3:24 PM, <noreply@launchpad.net> wrote:

------------------------------------------------------------
revno: 938
committer: Lars Helge Oeverland larshelge@gmail.com
branch nick: trunk
timestamp: Fri 2009-10-30 14:22:00 +0100
message:
Made the uniqueness constraint on CategoryOption back in. Will maintain it in a transition period.
modified:
dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java
dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java
dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java
dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml

--
lp:dhis2
trunk : Code : DHIS

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-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java'
--- dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java 2009-10-29 11:27:49 +0000
+++ dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java 2009-10-30 13:22:00 +0000
@@ -141,11 +141,11 @@
Collection<DataElementCategoryOption> getDataElementCategoryOptions( Collection<Integer> identifiers );
/\*\*
- * Retrieves the DataElementCategoryOptions with the given name.
+ * Retrieves the DataElementCategoryOption with the given name.
* @param name the name.
- * @return the DataElementCategoryOptions with the given name.
+ * @return the DataElementCategoryOption with the given name.
*/
- Collection<DataElementCategoryOption> getDataElementCategoryOptionsByName( String name );
+ DataElementCategoryOption getDataElementCategoryOptionByName( String name );
/\*\*
 \* Returns all DataElementCategoryOptions\.
=== modified file 'dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java'
--- dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java 2009-10-29 11:27:49 +0000
+++ dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java 2009-10-30 13:22:00 +0000
@@ -62,9 +62,9 @@
this.dataElementCategoryStore = dataElementCategoryStore;
}

- private GenericStore<DataElementCategoryOption> dataElementCategoryOptionStore;
+ private GenericIdentifiableObjectStore<DataElementCategoryOption> dataElementCategoryOptionStore;

- public void setDataElementCategoryOptionStore( GenericStore<DataElementCategoryOption> dataElementCategoryOptionStore )
+ public void setDataElementCategoryOptionStore( GenericIdentifiableObjectStore<DataElementCategoryOption> dataElementCategoryOptionStore )
{
this.dataElementCategoryOptionStore = dataElementCategoryOptionStore;
}
@@ -194,19 +194,9 @@
return dataElementCategoryOptionStore.get( id );
}

- public Collection<DataElementCategoryOption> getDataElementCategoryOptionsByName( String name )
+ public DataElementCategoryOption getDataElementCategoryOptionByName( String name )
{
- Collection<DataElementCategoryOption> categoryOptions = new ArrayList<DataElementCategoryOption>();
-
- for ( DataElementCategoryOption categoryOption : getAllDataElementCategoryOptions() )
- {
- if ( categoryOption.getName().equals( name ) )
- {
- categoryOptions.add( categoryOption );
- }
- }
-
- return categoryOptions;
+ return dataElementCategoryOptionStore.getByName( name );
}
public Collection&lt;DataElementCategoryOption&gt; getDataElementCategoryOptions\( Collection&lt;Integer&gt; identifiers \)
=== modified file 'dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java'
--- dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java 2009-10-20 10:51:16 +0000
+++ dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java 2009-10-30 13:22:00 +0000
@@ -106,7 +106,7 @@
//dataelementcategoryoption
executeSql( "ALTER TABLE dataelementcategoryoption DROP COLUMN shortname" );
executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT fk_dataelement_categoryid" );
- executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_name_key" );
+ //executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_name_key" ); will be maintained in transition period
executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_shortname_key" );
    log\.info\( &quot;Updated Category sort order and primary keys&quot; \);
=== modified file 'dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml'
--- dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml 2009-10-21 18:41:33 +0000
+++ dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml 2009-10-30 13:22:00 +0000
@@ -13,7 +13,7 @@
<property name="uuid" length="40"/>
&lt;property name=&quot;name&quot;&gt;
- <column name="name" not-null="true" length="160"/>
+ <column name="name" not-null="true" unique="true" length="160"/>
</property>
&lt;list name=&quot;categoryOptionCombos&quot; table=&quot;categoryoptioncombos\_categoryoptions&quot; inverse=&quot;true&quot;&gt;
_______________________________________________
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

Lars · 30 October 2009 13:53

It might be that there are none. This could be useful in the sense that if nobody asks for removing the constraint - we won’t.

···

On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering jason.p.pickering@gmail.com wrote:

Could some one remind me once again what the point of having a

category option in two separate categories is? is there a use case

here? It does not seem totally obvious, but maybe I am missing

something.

olatitle · 30 October 2009 14:19

I’ll give it a try:

Here are two categorycombos and their options:

CategoryCombo EPI Age Group + Gender
Category1: EPI Age Group
Options: (<1, >1)
Category2: Gender

Options (Female, Male)

CategoryCombo Morbidity Age Group + Gender
Category1: Morbidity Age Group
Options: (<1, 1-5, 5-15, >15)
Category2: Gender

Options (Female, Male)

The categoryoption name ‘<1’ is used in two different categories.

That said, I am not sure how useful it is to programatically know that <1 in Morbidity is the same as <1 in EPI (in the sense that you will use it in data analysis), even though they share the same name.

I find it useful to be able to do analysis on a random set of data elements across multiple dimensions (cetegories) independent of their categorycombos, e.g. in this example look at the gender dimenion across data elements from EPI and Morbidity. (although gender in EPI might not be a good real life example of something useful)

BUT I am not sure we need to support analysing data elements across a random set of categoryoptions independent of their categories, as in looking at the categoryoption ‘<1’ across EPI and Morbidity data elements. I find this to complex and far fetched to support.

As stated in that multidimensional datamart blueprint, we need to support e.g. report tables where the user can pick categoryoptions to use as columns, but I guess then we need to restrict it to a selection of categoryoptions within 1 categorycombo.

What I am saying is that although the same name is used in for options in two different categories it might not be necessary to actually link these two categoryoptions to the same master object or whatever you would call it. This means that the name is not the unique identifier for categoryoptions, but rather the name + the category it belongs to.

Does this make sense?

Ola

···

2009/10/30 Jason Pickering jason.p.pickering@gmail.com

Could some one remind me once again what the point of having a

category option in two separate categories is? is there a use case

here? It does not seem totally obvious, but maybe I am missing

something.

On Fri, Oct 30, 2009 at 3:24 PM, noreply@launchpad.net wrote:

revno: 938

committer: Lars Helge Oeverland larshelge@gmail.com

branch nick: trunk

timestamp: Fri 2009-10-30 14:22:00 +0100

message:

Made the uniqueness constraint on CategoryOption back in. Will maintain it in a transition period.

modified:

dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java

dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java

dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java

dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.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-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java’

— dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java 2009-10-29 11:27:49 +0000

+++ dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java 2009-10-30 13:22:00 +0000

@@ -141,11 +141,11 @@
Collection<DataElementCategoryOption> getDataElementCategoryOptions( Collection<Integer> identifiers );
/**
* Retrieves the DataElementCategoryOptions with the given name.
* Retrieves the DataElementCategoryOption with the given name.
 * @param name the name.
* @return the DataElementCategoryOptions with the given name.
* @return the DataElementCategoryOption with the given name.
 */
Collection getDataElementCategoryOptionsByName( String name );

DataElementCategoryOption getDataElementCategoryOptionByName( String name );
/**
 * Returns all DataElementCategoryOptions.
=== modified file ‘dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java’

— dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java 2009-10-29 11:27:49 +0000

+++ dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java 2009-10-30 13:22:00 +0000

@@ -62,9 +62,9 @@
    this.dataElementCategoryStore = dataElementCategoryStore;
}
private GenericStore dataElementCategoryOptionStore;

private GenericIdentifiableObjectStore dataElementCategoryOptionStore;

public void setDataElementCategoryOptionStore( GenericStore dataElementCategoryOptionStore )

public void setDataElementCategoryOptionStore( GenericIdentifiableObjectStore dataElementCategoryOptionStore )
{
    this.dataElementCategoryOptionStore = dataElementCategoryOptionStore;
}
@@ -194,19 +194,9 @@
    return dataElementCategoryOptionStore.get( id );
}
public Collection getDataElementCategoryOptionsByName( String name )

public DataElementCategoryOption getDataElementCategoryOptionByName( String name )
{
   Collection<DataElementCategoryOption> categoryOptions = new ArrayList<DataElementCategoryOption>();
   for ( DataElementCategoryOption categoryOption : getAllDataElementCategoryOptions() )
   {
       if ( categoryOption.getName().equals( name ) )
       {
           categoryOptions.add( categoryOption );
       }
   }
   return categoryOptions;
   return dataElementCategoryOptionStore.getByName( name );
}
public Collection<DataElementCategoryOption> getDataElementCategoryOptions( Collection<Integer> identifiers )
=== modified file ‘dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java’

— dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java 2009-10-20 10:51:16 +0000

+++ dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java 2009-10-30 13:22:00 +0000

@@ -106,7 +106,7 @@
    //dataelementcategoryoption
    executeSql( "ALTER TABLE dataelementcategoryoption DROP COLUMN shortname" );
    executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT fk_dataelement_categoryid" );
   executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_name_key" );
   //executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_name_key" ); will be maintained in transition period
    executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_shortname_key" );
    [log.info](http://log.info)( "Updated Category sort order and primary keys" );
=== modified file ‘dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml’

— dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml 2009-10-21 18:41:33 +0000

+++ dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml 2009-10-30 13:22:00 +0000

@@ -13,7 +13,7 @@
<property name="uuid" length="40"/>
<property name="name">
 <column name="name" not-null="true" length="160"/>
 <column name="name" not-null="true" unique="true" length="160"/>
</property>
<list name="categoryOptionCombos" table="categoryoptioncombos_categoryoptions" inverse="true">
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

bobj · 30 October 2009 14:37

Could some one remind me once again what the point of having a

category option in two separate categories is? is there a use case

here? It does not seem totally obvious, but maybe I am missing

something.

I’ll give it a try:

Here are two categorycombos and their options:

CategoryCombo EPI Age Group + Gender
Category1: EPI Age Group
Options: (<1, >1)
Category2: Gender

Options (Female, Male)

CategoryCombo Morbidity Age Group + Gender
Category1: Morbidity Age Group
Options: (<1, 1-5, 5-15, >15)
Category2: Gender

Options (Female, Male)

The categoryoption name ‘<1’ is used in two different categories.

That said, I am not sure how useful it is to programatically know that <1 in Morbidity is the same as <1 in EPI (in the sense that you will use it in data analysis), even though they share the same name.

I find it useful to be able to do analysis on a random set of data elements across multiple dimensions (cetegories) independent of their categorycombos, e.g. in this example look at the gender dimenion across data elements from EPI and Morbidity. (although gender in EPI might not be a good real life example of something useful)

BUT I am not sure we need to support analysing data elements across a random set of categoryoptions independent of their categories, as in looking at the categoryoption ‘<1’ across EPI and Morbidity data elements. I find this to complex and far fetched to support.

As stated in that multidimensional datamart blueprint, we need to support e.g. report tables where the user can pick categoryoptions to use as columns, but I guess then we need to restrict it to a selection of categoryoptions within 1 categorycombo.

What I am saying is that although the same name is used in for options in two different categories it might not be necessary to actually link these two categoryoptions to the same master object or whatever you would call it. This means that the name is not the unique identifier for categoryoptions, but rather the name + the category it belongs to.

Does this make sense?

Exactly. Except that we must eventually move away from the name (or visible label) being used as an identifier at all but that is for somewhere down the line …

Bob

···

2009/10/30 Ola Hodne Titlestad olatitle@gmail.com

2009/10/30 Jason Pickering jason.p.pickering@gmail.com

Ola

On Fri, Oct 30, 2009 at 3:24 PM, noreply@launchpad.net wrote:

revno: 938

committer: Lars Helge Oeverland larshelge@gmail.com

branch nick: trunk

timestamp: Fri 2009-10-30 14:22:00 +0100

message:

Made the uniqueness constraint on CategoryOption back in. Will maintain it in a transition period.

modified:

dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java

dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java

dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java

dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.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-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java’

— dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java 2009-10-29 11:27:49 +0000

+++ dhis-2/dhis-api/src/main/java/org/hisp/dhis/dataelement/DataElementCategoryService.java 2009-10-30 13:22:00 +0000

@@ -141,11 +141,11 @@
Collection<DataElementCategoryOption> getDataElementCategoryOptions( Collection<Integer> identifiers );
/**
* Retrieves the DataElementCategoryOptions with the given name.
* Retrieves the DataElementCategoryOption with the given name.
 * @param name the name.
* @return the DataElementCategoryOptions with the given name.
* @return the DataElementCategoryOption with the given name.
 */
Collection getDataElementCategoryOptionsByName( String name );

DataElementCategoryOption getDataElementCategoryOptionByName( String name );
/**
 * Returns all DataElementCategoryOptions.
=== modified file ‘dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java’

— dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java 2009-10-29 11:27:49 +0000

+++ dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/DefaultDataElementCategoryService.java 2009-10-30 13:22:00 +0000

@@ -62,9 +62,9 @@
    this.dataElementCategoryStore = dataElementCategoryStore;
}
private GenericStore dataElementCategoryOptionStore;

private GenericIdentifiableObjectStore dataElementCategoryOptionStore;

public void setDataElementCategoryOptionStore( GenericStore dataElementCategoryOptionStore )

public void setDataElementCategoryOptionStore( GenericIdentifiableObjectStore dataElementCategoryOptionStore )
{
    this.dataElementCategoryOptionStore = dataElementCategoryOptionStore;
}
@@ -194,19 +194,9 @@
    return dataElementCategoryOptionStore.get( id );
}
public Collection getDataElementCategoryOptionsByName( String name )

public DataElementCategoryOption getDataElementCategoryOptionByName( String name )
{
   Collection<DataElementCategoryOption> categoryOptions = new ArrayList<DataElementCategoryOption>();
   for ( DataElementCategoryOption categoryOption : getAllDataElementCategoryOptions() )
   {
       if ( categoryOption.getName().equals( name ) )
       {
           categoryOptions.add( categoryOption );
       }
   }
   return categoryOptions;
   return dataElementCategoryOptionStore.getByName( name );
}
public Collection<DataElementCategoryOption> getDataElementCategoryOptions( Collection<Integer> identifiers )
=== modified file ‘dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java’

— dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java 2009-10-20 10:51:16 +0000

+++ dhis-2/dhis-services/dhis-service-core/src/main/java/org/hisp/dhis/dataelement/OptionsCategoriesDefaultSortOrderPopulator.java 2009-10-30 13:22:00 +0000

@@ -106,7 +106,7 @@
    //dataelementcategoryoption
    executeSql( "ALTER TABLE dataelementcategoryoption DROP COLUMN shortname" );
    executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT fk_dataelement_categoryid" );
   executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_name_key" );
   //executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_name_key" ); will be maintained in transition period
    executeSql( "ALTER TABLE dataelementcategoryoption DROP CONSTRAINT dataelementcategoryoption_shortname_key" );
    [log.info](http://log.info)( "Updated Category sort order and primary keys" );
=== modified file ‘dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml’

— dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml 2009-10-21 18:41:33 +0000

+++ dhis-2/dhis-services/dhis-service-core/src/main/resources/org/hisp/dhis/dataelement/hibernate/DataElementCategoryOption.hbm.xml 2009-10-30 13:22:00 +0000

@@ -13,7 +13,7 @@
<property name="uuid" length="40"/>
<property name="name">
 <column name="name" not-null="true" length="160"/>
 <column name="name" not-null="true" unique="true" length="160"/>
</property>
<list name="categoryOptionCombos" table="categoryoptioncombos_categoryoptions" inverse="true">
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

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

Lars · 30 October 2009 14:38

To clarify: We are not reverting the 1-n association between category and category option. We are just putting back the uniqueness constraint on category option name to be backwards compatible. If we did not have to cater for that it wouldn’t be necessary to have that name constraint.

···

On Fri, Oct 30, 2009 at 3:19 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

2009/10/30 Jason Pickering jason.p.pickering@gmail.com

Could some one remind me once again what the point of having a

category option in two separate categories is? is there a use case

here? It does not seem totally obvious, but maybe I am missing

something.

I’ll give it a try:

Here are two categorycombos and their options:

CategoryCombo EPI Age Group + Gender
Category1: EPI Age Group
Options: (<1, >1)
Category2: Gender

Options (Female, Male)

CategoryCombo Morbidity Age Group + Gender
Category1: Morbidity Age Group
Options: (<1, 1-5, 5-15, >15)
Category2: Gender

Options (Female, Male)

The categoryoption name ‘<1’ is used in two different categories.

That said, I am not sure how useful it is to programatically know that <1 in Morbidity is the same as <1 in EPI (in the sense that you will use it in data analysis), even though they share the same name.

I find it useful to be able to do analysis on a random set of data elements across multiple dimensions (cetegories) independent of their categorycombos, e.g. in this example look at the gender dimenion across data elements from EPI and Morbidity. (although gender in EPI might not be a good real life example of something useful)

BUT I am not sure we need to support analysing data elements across a random set of categoryoptions independent of their categories, as in looking at the categoryoption ‘<1’ across EPI and Morbidity data elements. I find this to complex and far fetched to support.

As stated in that multidimensional datamart blueprint, we need to support e.g. report tables where the user can pick categoryoptions to use as columns, but I guess then we need to restrict it to a selection of categoryoptions within 1 categorycombo.

What I am saying is that although the same name is used in for options in two different categories it might not be necessary to actually link these two categoryoptions to the same master object or whatever you would call it. This means that the name is not the unique identifier for categoryoptions, but rather the name + the category it belongs to.

Does this make sense?

Ola

jason · 30 October 2009 14:41

OK, I took a walk around the block to think about this a bit more. I
think it does, make sense, sort of. Lets look at "Total", which might
be defined as a calculated data element, say composed of different age
groups. But the "Total" in this category, would not be the same as the
"Total" that might be defined in a different category, or would it?

Having a single categoryoption "Total" would allow one to slice out
particular groups of dimensional elements, which is a fairly common
operation as Ola mentions, with a single filter statement. Otherwise,
you would need to collect all of the "Total"s for different categories
through another table and perform an inner join, as opposed to a
filter. For multiple category options, I guess there would need to be
a decision made whether to perform an inner join or loop through a
filter, but I guess an inner join would actually be better for either
one or many category options (have not looked at the code). If the
uniqueness contraint is not there, the user would need to select in a
separate step to select all "Total"s and then perform an inner join,
as there would be no intrinsic relationship between "Total" in the
"Age" category and the "Total" in the "Gender" category. This might be
very tedious if there are many categories to select from. Having
multiple category options with the same name does not make sense in
this case, and I think this is what everyone is saying?

Obviously there should not be two category options called "Total" to
be within a single category/data element group set. However,I am not
sure I understand completely your point Ola. To me, the use case you
describe is very typical. "Give me all data for the under 1 age
group", "Give me all data on in patient discharges". Having to define
multiple "under 1" and "IPD" for each category seems to be very
inefficient, as well as painful.

So, I guess maybe I am answering my own mail...I think.

···

2009/10/30 Lars Helge Øverland <larshelge@gmail.com>:

On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering > <jason.p.pickering@gmail.com> wrote:

Could some one remind me once again what the point of having a
category option in two separate categories is? is there a use case
here? It does not seem totally obvious, but maybe I am missing
something.

It might be that there are none. This could be useful in the sense that if
nobody asks for removing the constraint - we won't.

olatitle · 30 October 2009 15:34

I thought the whole point of the category/categoryoption/categorycombo model was that the total would be the data element itself without any categoryoption? The “total” should then not be defined as one of the options, but be always be derived from the sum of all the options.

Your example Jason is from a 1.4 design point of view where you are not using this model, but normally need calculated data elements to get to a total (since the categoryoptions are part of the data element names). With the new data element group set model I guess you can derive the total for e.g. “Malaria new cases OPD” e.g. by filtering on the data element group “Malaria” in the group set “Diseases” plus the group called “New cases” in the group set “Patient status” and then simply sum up all the data elements in the two groups sets “Gender” and “Morbidity age group”. Would’t such an approach give you the totals you need?

As in exactly how we could accommodate that within DHIS2 e.g in a report table GUI I am not sure. Seems complicated and something for an OLAP tool to take care of.

Ola

···

2009/10/30 Jason Pickering jason.p.pickering@gmail.com

OK, I took a walk around the block to think about this a bit more. I

think it does, make sense, sort of. Lets look at “Total”, which might

be defined as a calculated data element, say composed of different age

groups. But the “Total” in this category, would not be the same as the

“Total” that might be defined in a different category, or would it?

Having a single categoryoption “Total” would allow one to slice out

particular groups of dimensional elements, which is a fairly common

operation as Ola mentions, with a single filter statement. Otherwise,

you would need to collect all of the "Total"s for different categories

through another table and perform an inner join, as opposed to a

filter. For multiple category options, I guess there would need to be

a decision made whether to perform an inner join or loop through a

filter, but I guess an inner join would actually be better for either

one or many category options (have not looked at the code). If the

uniqueness contraint is not there, the user would need to select in a

separate step to select all "Total"s and then perform an inner join,

as there would be no intrinsic relationship between “Total” in the

“Age” category and the “Total” in the “Gender” category. This might be

very tedious if there are many categories to select from. Having

multiple category options with the same name does not make sense in

this case, and I think this is what everyone is saying?

Obviously there should not be two category options called “Total” to

be within a single category/data element group set. However,I am not

sure I understand completely your point Ola. To me, the use case you

describe is very typical. "Give me all data for the under 1 age

group", “Give me all data on in patient discharges”. Having to define

multiple “under 1” and “IPD” for each category seems to be very

inefficient, as well as painful.

So, I guess maybe I am answering my own mail…I think.

2009/10/30 Lars Helge Øverland larshelge@gmail.com:

On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering > > > jason.p.pickering@gmail.com wrote:

Could some one remind me once again what the point of having a

category option in two separate categories is? is there a use case

here? It does not seem totally obvious, but maybe I am missing

something.

It might be that there are none. This could be useful in the sense that if

nobody asks for removing the constraint - we won’t.

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

jason · 30 October 2009 15:53

Perhaps it is a bad example but it raises a good point, and we might
should move this to a new thread if it continues to balloon.

My understanding was the category options would be used for data
entry. This is not really an issue about 1.4, it is really an issue
about whether people will enter totals or not. There is nothing to
prevent people from defining a category , Gender, with three (or more)
options, "Male" "Female" and "Total", and it may be necessary. Let me
explain. On the paper tools used here in Zambia, there is a separate
column "Total" which is the sum of three age groups (Under 1, 1-5 and
Over 5). If I was going to implement the multidimensional data
elements here, if I wanted to replicate the paper tool exactly, I
would need a separate column for totals. This is what we have now, and
it serves a good purpose, as the data entry personnel can see if the
totals provided by the facility actually match the calculated totals.
No idea if this is how the categories work in DHIS2. But from the
analysis standpoint, it would seem that you would need some calculated
data element as well that would calculate the total from the
multidimensional components of the data element, unless as you say,
you are going to rely on OLAP or PivotTables to always do this
aggregation for you. I would think that actually having the ability to
persist and store the data value, as a calculated data element (Save
calculated) and assign it a Category option of "Total" (which might be
implicit anyway in the system) would make sense, since you might need
it directly in a report or something and do not want to have to revert
to OLAP or custom SQL to get this. But again, I am looking at this
from the perspective of a bunch of data elements which do not use
category options.

You would get the totals as you state, but only by using OLAP. What
about if I want to create an Excel report with only Totals? Now if the
new model will automatically give me the totals from the component
dimensions, great, but I did not see this in the blueprint. I was
assuming that I would need explicitly define a separate, calculated
element for this.

Regards,
Jason

···

On Fri, Oct 30, 2009 at 5:34 PM, Ola Hodne Titlestad <olatitle@gmail.com> wrote:

2009/10/30 Jason Pickering <jason.p.pickering@gmail.com>

OK, I took a walk around the block to think about this a bit more. I
think it does, make sense, sort of. Lets look at "Total", which might
be defined as a calculated data element, say composed of different age
groups. But the "Total" in this category, would not be the same as the
"Total" that might be defined in a different category, or would it?

I thought the whole point of the category/categoryoption/categorycombo model
was that the total would be the data element itself without any
categoryoption? The "total" should then not be defined as one of the
options, but be always be derived from the sum of all the options.

Your example Jason is from a 1.4 design point of view where you are not
using this model, but normally need calculated data elements to get to a
total (since the categoryoptions are part of the data element names). With
the new data element group set model I guess you can derive the total for
e.g. "Malaria new cases OPD" e.g. by filtering on the data element group
"Malaria" in the group set "Diseases" plus the group called "New cases" in
the group set "Patient status" and then simply sum up all the data elements
in the two groups sets "Gender" and "Morbidity age group". Would't such an
approach give you the totals you need?

As in exactly how we could accommodate that within DHIS2 e.g in a report
table GUI I am not sure. Seems complicated and something for an OLAP tool to
take care of.

Ola
-----------

Having a single categoryoption "Total" would allow one to slice out
particular groups of dimensional elements, which is a fairly common
operation as Ola mentions, with a single filter statement. Otherwise,
you would need to collect all of the "Total"s for different categories
through another table and perform an inner join, as opposed to a
filter. For multiple category options, I guess there would need to be
a decision made whether to perform an inner join or loop through a
filter, but I guess an inner join would actually be better for either
one or many category options (have not looked at the code). If the
uniqueness contraint is not there, the user would need to select in a
separate step to select all "Total"s and then perform an inner join,
as there would be no intrinsic relationship between "Total" in the
"Age" category and the "Total" in the "Gender" category. This might be
very tedious if there are many categories to select from. Having
multiple category options with the same name does not make sense in
this case, and I think this is what everyone is saying?

Obviously there should not be two category options called "Total" to
be within a single category/data element group set. However,I am not
sure I understand completely your point Ola. To me, the use case you
describe is very typical. "Give me all data for the under 1 age
group", "Give me all data on in patient discharges". Having to define
multiple "under 1" and "IPD" for each category seems to be very
inefficient, as well as painful.

So, I guess maybe I am answering my own mail...I think.

2009/10/30 Lars Helge Øverland <larshelge@gmail.com>:
>
>
> On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering >> > <jason.p.pickering@gmail.com> wrote:
>>
>> Could some one remind me once again what the point of having a
>> category option in two separate categories is? is there a use case
>> here? It does not seem totally obvious, but maybe I am missing
>> something.
>>
>
> It might be that there are none. This could be useful in the sense that
> if
> nobody asks for removing the constraint - we won't.
>
>
>

_______________________________________________
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

bobj · 30 October 2009 16:17

This sounds like a simple GUI feature request rather than something fundamental about categories.

Request: an option to generate totals column for category options. Not that it should be stored.

In general I think I would view having “Total” categoryoptions as a proverbial bad thing.

Mind you this is a distraction from the general question …

···

2009/10/30 Jason Pickering jason.p.pickering@gmail.com

Perhaps it is a bad example but it raises a good point, and we might

should move this to a new thread if it continues to balloon.

My understanding was the category options would be used for data

entry. This is not really an issue about 1.4, it is really an issue

about whether people will enter totals or not. There is nothing to

prevent people from defining a category , Gender, with three (or more)

options, “Male” “Female” and “Total”, and it may be necessary. Let me

explain. On the paper tools used here in Zambia, there is a separate

column “Total” which is the sum of three age groups (Under 1, 1-5 and

Over 5). If I was going to implement the multidimensional data

elements here, if I wanted to replicate the paper tool exactly, I

would need a separate column for totals. This is what we have now, and

it serves a good purpose, as the data entry personnel can see if the

totals provided by the facility actually match the calculated totals.

No idea if this is how the categories work in DHIS2. But from the

analysis standpoint, it would seem that you would need some calculated

data element as well that would calculate the total from the

multidimensional components of the data element, unless as you say,

you are going to rely on OLAP or PivotTables to always do this

aggregation for you. I would think that actually having the ability to

persist and store the data value, as a calculated data element (Save

calculated) and assign it a Category option of “Total” (which might be

implicit anyway in the system) would make sense, since you might need

it directly in a report or something and do not want to have to revert

to OLAP or custom SQL to get this. But again, I am looking at this

from the perspective of a bunch of data elements which do not use

category options.

You would get the totals as you state, but only by using OLAP. What

about if I want to create an Excel report with only Totals? Now if the

new model will automatically give me the totals from the component

dimensions, great, but I did not see this in the blueprint. I was

assuming that I would need explicitly define a separate, calculated

element for this.

Regards,

Jason

On Fri, Oct 30, 2009 at 5:34 PM, Ola Hodne Titlestad olatitle@gmail.com wrote:

2009/10/30 Jason Pickering jason.p.pickering@gmail.com

OK, I took a walk around the block to think about this a bit more. I

think it does, make sense, sort of. Lets look at “Total”, which might

be defined as a calculated data element, say composed of different age

groups. But the “Total” in this category, would not be the same as the

“Total” that might be defined in a different category, or would it?

I thought the whole point of the category/categoryoption/categorycombo model

was that the total would be the data element itself without any

categoryoption? The “total” should then not be defined as one of the

options, but be always be derived from the sum of all the options.

Your example Jason is from a 1.4 design point of view where you are not

using this model, but normally need calculated data elements to get to a

total (since the categoryoptions are part of the data element names). With

the new data element group set model I guess you can derive the total for

e.g. “Malaria new cases OPD” e.g. by filtering on the data element group

“Malaria” in the group set “Diseases” plus the group called “New cases” in

the group set “Patient status” and then simply sum up all the data elements

in the two groups sets “Gender” and “Morbidity age group”. Would’t such an

approach give you the totals you need?

As in exactly how we could accommodate that within DHIS2 e.g in a report

table GUI I am not sure. Seems complicated and something for an OLAP tool to

take care of.

Ola

Having a single categoryoption “Total” would allow one to slice out

particular groups of dimensional elements, which is a fairly common

operation as Ola mentions, with a single filter statement. Otherwise,

you would need to collect all of the "Total"s for different categories

through another table and perform an inner join, as opposed to a

filter. For multiple category options, I guess there would need to be

a decision made whether to perform an inner join or loop through a

filter, but I guess an inner join would actually be better for either

one or many category options (have not looked at the code). If the

uniqueness contraint is not there, the user would need to select in a

separate step to select all "Total"s and then perform an inner join,

as there would be no intrinsic relationship between “Total” in the

“Age” category and the “Total” in the “Gender” category. This might be

very tedious if there are many categories to select from. Having

multiple category options with the same name does not make sense in

this case, and I think this is what everyone is saying?

Obviously there should not be two category options called “Total” to

be within a single category/data element group set. However,I am not

sure I understand completely your point Ola. To me, the use case you

describe is very typical. "Give me all data for the under 1 age

group", “Give me all data on in patient discharges”. Having to define

multiple “under 1” and “IPD” for each category seems to be very

inefficient, as well as painful.

So, I guess maybe I am answering my own mail…I think.

2009/10/30 Lars Helge Øverland larshelge@gmail.com:

On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering > > >> > jason.p.pickering@gmail.com wrote:

Could some one remind me once again what the point of having a

category option in two separate categories is? is there a use case

here? It does not seem totally obvious, but maybe I am missing

something.

It might be that there are none. This could be useful in the sense that

if

nobody asks for removing the constraint - we won’t.

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

jason · 30 October 2009 16:48

I am not in agreement but will formulate a longer response on a
seperate thread. Jason

···

On 10/30/09, Bob Jolliffe <bobjolliffe@gmail.com> wrote:

This sounds like a simple GUI feature request rather than something
fundamental about categories.

Request: an option to generate totals column for category options. Not that
it should be stored.

In general I think I would view having "Total" categoryoptions as a
proverbial bad thing.

Mind you this is a distraction from the general question ....

2009/10/30 Jason Pickering <jason.p.pickering@gmail.com>

Perhaps it is a bad example but it raises a good point, and we might
should move this to a new thread if it continues to balloon.

My understanding was the category options would be used for data
entry. This is not really an issue about 1.4, it is really an issue
about whether people will enter totals or not. There is nothing to
prevent people from defining a category , Gender, with three (or more)
options, "Male" "Female" and "Total", and it may be necessary. Let me
explain. On the paper tools used here in Zambia, there is a separate
column "Total" which is the sum of three age groups (Under 1, 1-5 and
Over 5). If I was going to implement the multidimensional data
elements here, if I wanted to replicate the paper tool exactly, I
would need a separate column for totals. This is what we have now, and
it serves a good purpose, as the data entry personnel can see if the
totals provided by the facility actually match the calculated totals.
No idea if this is how the categories work in DHIS2. But from the
analysis standpoint, it would seem that you would need some calculated
data element as well that would calculate the total from the
multidimensional components of the data element, unless as you say,
you are going to rely on OLAP or PivotTables to always do this
aggregation for you. I would think that actually having the ability to
persist and store the data value, as a calculated data element (Save
calculated) and assign it a Category option of "Total" (which might be
implicit anyway in the system) would make sense, since you might need
it directly in a report or something and do not want to have to revert
to OLAP or custom SQL to get this. But again, I am looking at this
from the perspective of a bunch of data elements which do not use
category options.

You would get the totals as you state, but only by using OLAP. What
about if I want to create an Excel report with only Totals? Now if the
new model will automatically give me the totals from the component
dimensions, great, but I did not see this in the blueprint. I was
assuming that I would need explicitly define a separate, calculated
element for this.

Regards,
Jason

On Fri, Oct 30, 2009 at 5:34 PM, Ola Hodne Titlestad <olatitle@gmail.com> >> wrote:
> 2009/10/30 Jason Pickering <jason.p.pickering@gmail.com>
>>
>> OK, I took a walk around the block to think about this a bit more. I
>> think it does, make sense, sort of. Lets look at "Total", which might
>> be defined as a calculated data element, say composed of different age
>> groups. But the "Total" in this category, would not be the same as the
>> "Total" that might be defined in a different category, or would it?
>>
>
> I thought the whole point of the category/categoryoption/categorycombo
model
> was that the total would be the data element itself without any
> categoryoption? The "total" should then not be defined as one of the
> options, but be always be derived from the sum of all the options.
>
> Your example Jason is from a 1.4 design point of view where you are not
> using this model, but normally need calculated data elements to get to a
> total (since the categoryoptions are part of the data element names).
With
> the new data element group set model I guess you can derive the total
> for
> e.g. "Malaria new cases OPD" e.g. by filtering on the data element
> group
> "Malaria" in the group set "Diseases" plus the group called "New cases"
in
> the group set "Patient status" and then simply sum up all the data
elements
> in the two groups sets "Gender" and "Morbidity age group". Would't such
an
> approach give you the totals you need?
>
> As in exactly how we could accommodate that within DHIS2 e.g in a report
> table GUI I am not sure. Seems complicated and something for an OLAP
> tool
to
> take care of.
>
> Ola
> -----------
>
>> Having a single categoryoption "Total" would allow one to slice out
>> particular groups of dimensional elements, which is a fairly common
>> operation as Ola mentions, with a single filter statement. Otherwise,
>> you would need to collect all of the "Total"s for different categories
>> through another table and perform an inner join, as opposed to a
>> filter. For multiple category options, I guess there would need to be
>> a decision made whether to perform an inner join or loop through a
>> filter, but I guess an inner join would actually be better for either
>> one or many category options (have not looked at the code). If the
>> uniqueness contraint is not there, the user would need to select in a
>> separate step to select all "Total"s and then perform an inner join,
>> as there would be no intrinsic relationship between "Total" in the
>> "Age" category and the "Total" in the "Gender" category. This might be
>> very tedious if there are many categories to select from. Having
>> multiple category options with the same name does not make sense in
>> this case, and I think this is what everyone is saying?
>>
>>
>>
>> Obviously there should not be two category options called "Total" to
>> be within a single category/data element group set. However,I am not
>> sure I understand completely your point Ola. To me, the use case you
>> describe is very typical. "Give me all data for the under 1 age
>> group", "Give me all data on in patient discharges". Having to define
>> multiple "under 1" and "IPD" for each category seems to be very
>> inefficient, as well as painful.
>>
>> So, I guess maybe I am answering my own mail...I think.
>>
>>
>>
>>
>> 2009/10/30 Lars Helge Øverland <larshelge@gmail.com>:
>> >
>> >
>> > On Fri, Oct 30, 2009 at 2:43 PM, Jason Pickering >> >> > <jason.p.pickering@gmail.com> wrote:
>> >>
>> >> Could some one remind me once again what the point of having a
>> >> category option in two separate categories is? is there a use case
>> >> here? It does not seem totally obvious, but maybe I am missing
>> >> something.
>> >>
>> >
>> > It might be that there are none. This could be useful in the sense
that
>> > if
>> > nobody asks for removing the constraint - we won't.
>> >
>> >
>> >
>>
>> _______________________________________________
>> Mailing list:
>> https://launchpad.net/~dhis2-devs<https://launchpad.net/~dhis2-devs>
>> Post to : dhis2-devs@lists.launchpad.net
>> Unsubscribe :
>> https://launchpad.net/~dhis2-devs<https://launchpad.net/~dhis2-devs>
>> More help : https://help.launchpad.net/ListHelp
>
>

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

--
Sent from my mobile device