dhis2-devs team mailing list archive

[Jo Størset <storset@xxxxxxxxx>]

Hi,

moving to the list, as I have some general questions I want to discuss on the mapping (I have attached an example of the impact of annotating the entities directly with jaxb).

Den 15. des. 2009 kl. 01.59 skrev Bob Jolliffe:

> Ok not realy a mistake so much as a flight of fancy.  I had been playing with the direction of these associations in order to optimize the ordering of elements. 

Ok, I thought maybe this optimization might be necessary. 

> Just checked in revised version which follows the model more literally which will make mapping easier.  And updated sample.  And added some missing elements of orgunit. 

Great. 

> As an aside, there are generally a lot of empty elements which can be quite costly if we are expressing a great many orgunits.  I can probably make most of these optional ie. if there is no url (Null in database) there is no need to create <url/> tag.  This would be particularly useful with the date elements.  Currently they are typed text rather than date otherwise empty elements don't validate.  I think its better to rather enforce the date type and allow the element to be optional.  Any thoughts?  There are lots of elements in the metadata (eg dataElement) where this is the case.

Personally I like less xml and more enforcing :) It does mean a more job, though.

On the general questions:

I like the fact that the consequences of changes to entities for the xml mapping is visible on the entity itself. The domain model is generally complex enough that this direct visibility will help a lot in visualizing the concequences of changes. We can add things to the model without to much problems, and to a certain degree "generalize" the contents of existing elements. But we are enforcing a stabilization of the api, the underlying model can´t really change without rethinking the xml mapping. And the proposed approach is rather inflexible and doesn´t handle mulitple versions very well (if we need to support multiple xml formats). How much do we expect the domain model to change and needing to be "backwards compatible"?

The real question is a general one; how do we think the api (and the xml formats we want to support) will evolve in the future? I don´t think we can avoid the rising cost of changes to the domain model, but we should try to make a concious choice on where we think we are going, before I create a new mapping solution. Some possiblities:

1) Proposed jaxb mapping, generally not supporting multiple xml versions - visible, easy, but no support for old formats
2) Something like the existing "mapping layer" - low visibility, easier to support multiple separate xml versions (but rising uncertainty of entity changes for every version)
3) jaxb and "versioned" domain models - visible, reflecting the (real) complexity of different api versions in the domain model

I don´t think we are at a point yet where we are sold on the approach we choose now, but obviously I would prefer not have to rewrite the mapping approach in the near future. I haven´t really looked at the feasibility of trying to do something like 3, but I think it should be to introduce such a model on parts of the domain model when needed, starting from 1.

Personally I prefer to try 1, what do you think?

Jo

Attachment: OrganisationUnitGroupSet.java
Description: Binary data