dhis2-devs team mailing list archive

[Jo Størset <storset@xxxxxxxxx>]

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

> 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
> 
> I have for some time been proposing to Lars that the marshalling and unmarshalling of domain objects should be part of the API.  There are lots of advantages but I have come around to his thinking that decoupling these is in fact important.  Primarily because I think there will be ongoing tweaks to the domain model.  Particularly I expect we will do at least one more refactor of mcdonalds (categories, combo's etc).
>  
> 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?
> 
> My thinking was some combination of 2 and 3.  A jaxb set of marshalling/unmarshalling classes which are bound to a namespaced version.  And then mapping these to the domain model.  Not as neat as a direct jaxb mapping but more flexible.

I´m not entirely convinced that it will be that much more flexible. I mean, it really depends on how important backwards compability will be, and currently the domain model is a bit too changing to warrant it. So, at the moment I tend to think that planned breaking changes to a single export format would be preferable. The added complexity and extra resources needed to maintain a separate mapping layer and multiple versions just seem to outweigh the benefits. If we don´t have that many concrete use cases in the short term, the cost of upgrading them seems preferable?

On another note, I don´t think jaxb makes a lot of sense if we go for a separate layer. I would tend to favour a solution more like the current framework, simpler and with less boilerplate overhead.

Jo