← Back to team overview

dhis2-devs team mailing list archive

Re: Should we remove the Source object?

 

Hi,



----- Original Message ----
From: Lars Helge Øverland <larshelge@xxxxxxxxx>
To: DHIS 2 developers <dhis2-devs@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, August 26, 2009 6:56:46 PM
Subject: [Dhis2-devs] Should we remove the Source object?

Hi,

I have been thinking about removing the Source object from the API.
The abstract Source class was introduced in the model in order to
allow for multiple implementations of Sources in the system. Currently
we only have the OrganisationUnit object extending Source. We now see
eg. with Abyot's CHIS module that even if we need a new kind of
Source; the Patient, we still need the OrganisationUnit reference in
DataValue.

The downsides of keeping Source are that it

- Increases complexity.
- Makes JDBC/Hibernate operations slower, since the Source table must
be updated first, then the orgunit table.
- Entails problems when people manually modifies the database (which
they really should not) as they always forget to update the source
table when adding/removing from the organisationunit table.

The only database update this would require is to set the
"organisationunitid" field in the "organisationunit" table to
auto-increment. I believe Hibernate will take care of this.

Based on this I opt for removing the Source object and moving the
OrganisationUnit object into the core.

Are there other aspects regarding this that should be mentioned? Any objections?


regards


Lars

Just looked at Source class, it has some commonly used attributes for hibernated objects (needed by hibernated objects, not any business logic at all), it does not give any value to organisationunit class. Moreover its ID attribute and its storage to database is excessive. Useful object to me for example could be relation to resolve hierarchy, if say source class had attributes parent and childs, and other implementing classes could use it reducing code lines and maintenance, bringing all into interface:

private Object parent;
private List<Object> children;

gettersetters. This could be good for implementations with hierarchy on their business logic. 

I agree with removal as it does nothing, but one precaution - 
if it was used by modules as object via hibernate, those need fixing too. Look at datavalue class, it has Source class as attribute, maybe this is due to lightweightness of Source compared to Organisationunit? We have more load on datavalue object read and manipulation. 

regards,
murod
_______________________________________________
Mailing list: https://launchpad.net/~dhis2-devs
Post to     : dhis2-devs@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~dhis2-devs
More help   : https://help.launchpad.net/ListHelp







References