dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

On 20 February 2013 07:59, Lars Helge Øverland <larshelge@xxxxxxxxx> wrote:

> Hi,
>
> sorry for the late reply.
>
>
>> It was later discovered, probably when making pivot table views for
>> Excel would be my guess, that in fact a persisted name is quite handy
>> - many times easier than doing the sql equivalent of what is is done
>> in java to produce "(Male,<1)" (or "(<1,Male)" ).  So we created the
>> _catoptcomboname table.
>
>
> 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.

Still this is far from the most pressing of our concerns ..



>
> The reason for the sort order flaw is a bit boring. The association
> between category option and option combination is bi-directional. Category
> option - > option combination is represented as a Java List, which is an
> ordered collection. Option combination -> category option is represented as
> a Java Set, which is an unordered collection. The reason for this is that
> maintaining a bidirectional association with Lists in both ends does not
> make sense - you might get conflicts when you have overlapping objects.
>
> So for the resource table I can see we use the Set association from option
> combination -> category option to render the names. We should ideally use
> the association from the other end to maintain sort order. Will see if we
> can fix this shortly.
>
> regards,
>
> Lars
>
>