2009/12/15 Jo Størset <[email protected]> > 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. >
I will do that - but probably tomorrow. > > 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 > 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. Bob > > Jo > >
_______________________________________________ Mailing list: https://launchpad.net/~dhis2-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~dhis2-devs More help : https://help.launchpad.net/ListHelp
