What is the point of the categoryoptioncomboname table??

It seems to me this table only serves to hide the name from the
categoryoptioncombo table. Isn't this just adding to the complexity
(and confusion) of the multidiemensional makeup?

Could we not just add the name to categoryoptioncombo?

Knut

Its not
categoryoptioncombo but _
categoryoptioncombo . Its a resource table and not part of the model. Adding extra columns to domain model tables is bad practice.

Lars

···

On Mon, Nov 15, 2010 at 3:38 PM, Knut Staring knutst@gmail.com wrote:

It seems to me this table only serves to hide the name from the

categoryoptioncombo table. Isn’t this just adding to the complexity

(and confusion) of the multidiemensional makeup?

Could we not just add the name to categoryoptioncombo?

Knut


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

Its not categoryoptioncombo but _categoryoptioncombo. Its a resource table and not part of the model

You mean that it is "_categoryoptioncomboname" and not
"categoryoptioncomboname", and that this is a resource table, right?
In other words, a table that gets generated?

Adding extra columns to domain model tables is bad practice.

Ok, but can you tell me where else the names are stored? In other
words, how to populate the database directly with hundreds of
optionscombos?

Knut

···

2010/11/15 Lars Helge Øverland <larshelge@gmail.com>:

Lars

On Mon, Nov 15, 2010 at 3:38 PM, Knut Staring <knutst@gmail.com> wrote:

It seems to me this table only serves to hide the name from the
categoryoptioncombo table. Isn't this just adding to the complexity
(and confusion) of the multidiemensional makeup?

Could we not just add the name to categoryoptioncombo?

Knut

_______________________________________________
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

--
Cheers,
Knut Staring

Sorry, I'm confused. In the db from Malawi, the table is called
categoryoptioncomboname with no underscore in front.

I also don't quite understand what the bad practice consists in - do
you mean that refactoring (adding the missing name) will break
backwards compatibility?

Knut

···

2010/11/15 Knut Staring <knutst@gmail.com>:

2010/11/15 Lars Helge Øverland <larshelge@gmail.com>:

Its not categoryoptioncombo but _categoryoptioncombo. Its a resource table and not part of the model

You mean that it is "_categoryoptioncomboname" and not
"categoryoptioncomboname", and that this is a resource table, right?
In other words, a table that gets generated?

Adding extra columns to domain model tables is bad practice.

Ok, but can you tell me where else the names are stored? In other
words, how to populate the database directly with hundreds of
optionscombos?

Knut

Lars

On Mon, Nov 15, 2010 at 3:38 PM, Knut Staring <knutst@gmail.com> wrote:

It seems to me this table only serves to hide the name from the
categoryoptioncombo table. Isn't this just adding to the complexity
(and confusion) of the multidiemensional makeup?

Could we not just add the name to categoryoptioncombo?

Knut

_______________________________________________
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

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

Ok, I see it now - the combined name is generated based on the names
in the dataelementcategoryoption table.

I think it could be a bit clearer if we did add that underscore and
also if we could rename the dataelementcategoryoption table to just
categoryoption, to be consistent with the categories_categoryoptions
name.

Knut

···

2010/11/15 Knut Staring <knutst@gmail.com>:

Sorry, I'm confused. In the db from Malawi, the table is called
categoryoptioncomboname with no underscore in front.

I also don't quite understand what the bad practice consists in - do
you mean that refactoring (adding the missing name) will break
backwards compatibility?

Knut

2010/11/15 Knut Staring <knutst@gmail.com>:

2010/11/15 Lars Helge Øverland <larshelge@gmail.com>:

Its not categoryoptioncombo but _categoryoptioncombo. Its a resource table and not part of the model

You mean that it is "_categoryoptioncomboname" and not
"categoryoptioncomboname", and that this is a resource table, right?
In other words, a table that gets generated?

Adding extra columns to domain model tables is bad practice.

Ok, but can you tell me where else the names are stored? In other
words, how to populate the database directly with hundreds of
optionscombos?

Knut

Lars

On Mon, Nov 15, 2010 at 3:38 PM, Knut Staring <knutst@gmail.com> wrote:

It seems to me this table only serves to hide the name from the
categoryoptioncombo table. Isn't this just adding to the complexity
(and confusion) of the multidiemensional makeup?

Could we not just add the name to categoryoptioncombo?

Knut

_______________________________________________
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

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

While we are at it, we could rename the dataelementcategory table to
just category (though dimension would be even more consistent with
common OLAP practice, I think). This also makes sense since logically,
indicators can also be broken down along dimensions, not only
dataelements, right?

This is not urgent, but if you agree with it, I will be happy to
create a blueprint and brush up on the documentation of it.

Knut

···

2010/11/15 Knut Staring <knutst@gmail.com>:

Ok, I see it now - the combined name is generated based on the names
in the dataelementcategoryoption table.

I think it could be a bit clearer if we did add that underscore and
also if we could rename the dataelementcategoryoption table to just
categoryoption, to be consistent with the categories_categoryoptions
name.

Knut

2010/11/15 Knut Staring <knutst@gmail.com>:

Sorry, I'm confused. In the db from Malawi, the table is called
categoryoptioncomboname with no underscore in front.

I also don't quite understand what the bad practice consists in - do
you mean that refactoring (adding the missing name) will break
backwards compatibility?

Knut

2010/11/15 Knut Staring <knutst@gmail.com>:

2010/11/15 Lars Helge Øverland <larshelge@gmail.com>:

Its not categoryoptioncombo but _categoryoptioncombo. Its a resource table and not part of the model

You mean that it is "_categoryoptioncomboname" and not
"categoryoptioncomboname", and that this is a resource table, right?
In other words, a table that gets generated?

Adding extra columns to domain model tables is bad practice.

Ok, but can you tell me where else the names are stored? In other
words, how to populate the database directly with hundreds of
optionscombos?

Knut

Lars

On Mon, Nov 15, 2010 at 3:38 PM, Knut Staring <knutst@gmail.com> wrote:

It seems to me this table only serves to hide the name from the
categoryoptioncombo table. Isn't this just adding to the complexity
(and confusion) of the multidiemensional makeup?

Could we not just add the name to categoryoptioncombo?

Knut

_______________________________________________
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

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring

--
Cheers,
Knut Staring