dhis2-devs team mailing list archive

[Lars Helge Øverland <larshelge@xxxxxxxxx>]

> This is right. The names when used inside the application are generated on
>> the fly based on the category options and category combination. When
>> creating SQL reports, however, it is tricky to generate this (for anyone
>> except Jason that is;), so we decided to have a resource table for it. The
>> reason for not putting it on the categoryoptioncombo table is that this
>> table is generated by Hibernate and is part of the domain model - it is by
>> many people including me considered bad practice to tamper with entity
>> database tables. Having a separate table is cleaner and not really a
>> problem. One might also want to expand this with more information later.
>>
>
> My suggestion was that the name should be part of the model, not that we
> just add columns to the entity tables, which I agree would be bad.  The
> categoryoptioncombo name *is* part of the java implementation of the model.
>  In fact it currently even extends BaseNameableObject.  And there is a
> working assumption in the system that these things have names.  Everything
> else in our model with a name has a field added to the model rather than a
> separate table.  So it would have been good practice (I think) to maintain
> the pattern.
>
>
Yup agree that could have some benefits. But its different in the way that
we would never set the name explicitly like we do with all other objects.
So since we need to auto-generate the name anyway there is not much point
in persisting it... Anyway like you say, not the most pressing issue.