dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

2009/12/15 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?
>

OK.  I would say go with what you are convinced by.  We can always
pre-process old versions on the way in to massage them into whatever is
current if the need arises.

Regards
Bob

>
> 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
>