-
Notifications
You must be signed in to change notification settings - Fork 27
Technical Minutes 2021 05 20
- In attendance: Andreas S, Andrew C, Anton H, Craig V, Erwin S, Kor O, Thomas P
1. Adding 2 Types in ReproParturitionEventResource (#191)
We discussed- adding the fields BirthSize (country-specific extension not in the standard) and BirthStatus to the Parturition Event. There was much discussion about the different values used in different countries. Many solutions were suggested.
One possibility was to have a superset of values for BirthSize and translate it into your own country. BirthStatus also has different values, e.g. different periods when a tag is required. A useful approach is gathering what is used in different countries and see if we can find something in common that we can use. Our first task is to compile some country lists so we can create the starting point for a master list.
2. New values for production purposes - Breeding, SucklerCow (#215)
There was general agreement with the principle of adding the terms Breeding and SucklerCow to the set of purposes but no conclusion on the specific terms to be used. Our action is that we will look for some synonyms.
3. Remove DoNotBreed from animal (#213)
We are leaning towards a BreedControl event with values DoNotBreed or AllowBreeding. There was discussion on whether it should be a boolean or an enumeration.
4. Breaking events up and doing a post (including #154)
Anton H had started on breaking events up in his branch. It is working pretty well but the main problem is that it does not generate as expected. Leave Anton to do some more investigation and to solve the problems.
Andrew C also had a go at splitting but he did it much more simply. An issue in the approach is that there is duplication in the files. Andrew did one for Health. It allowed him to do a single event post or a post to batches. He has done a pull request so that we can get the code and review it. If you get a 200, it is recommended to return the full response. Whereas if you get a 201, you are supposed to return the URI of the response. 202 says I have accepted it but I have not necessarily added it. Andrew was keen to pick up the extended problem details object that was defined in one of the other issues and put that in as the errors object but he has still to do that.
There was discussion about the response message for batches, particularly if there was partial failure/success. It was discussed previously and people were in favour of accepting all good values immediately and rejecting the bad ones. But it was not solving Anton's problem. More discussion is needed.
If you sent some data, some was accepted and some rejected, what is the response going to give you? Is it going to give you an error, a problem details object with all the errors, or is it going to give you your successful fields with their new ids. Or is there some merge of these two? That's the bit we still need to nail down.
Andrew's prototype assumed they were all good and returned the array of objects or it was rejected and returned the array of errors. There is a case to say you want to return both the successful objects and the errors. Comment on the pull request to comment on how we deal with partial success.
Next meeting scheduled for 3 June 2021 at 8:15am CET