Stream: implementers
Topic: Was ContractTypeCodesEnum removed from ca.uhn.fhir.model.dst
Anthony Sute (Jul 14 2016 at 15:00):
We attempted migration from HAPI 1.4 to 1.6 this week and discovered that both 1.5 and 1.6 cause build errors in our application:
[INFO] --- maven-compiler-plugin:3.5.1:testCompile (default-testCompile) @ iexhub ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 2 source files to C:\InfoExchangeHubGIT\iexhub\iexhub\target\test-classes
C:\InfoExchangeHubGIT\iexhub\iexhub\src\test\java\org\iexhub\services\test\ResearchConsentTest.java:43: error: cannot find symbol
import ca.uhn.fhir.model.dstu2.valueset.ContractTypeCodesEnum;
^
symbol: class ContractTypeCodesEnum
location: package ca.uhn.fhir.model.dstu2.valueset
C:\InfoExchangeHubGIT\iexhub\iexhub\src\test\java\org\iexhub\services\test\PrivacyConsentTest.java:41: error: cannot find symbol
import ca.uhn.fhir.model.dstu2.valueset.ContractTypeCodesEnum;
^
symbol: class ContractTypeCodesEnum
location: package ca.uhn.fhir.model.dstu2.valueset
2 errors
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 04:35 min
[INFO] Finished at: 2016-07-12T18:42:52-04:00
[INFO] Final Memory: 226M/247M
[INFO] ------------------------------------------------------------------------
Was the ContractTypeCodesEnum class removed from the ca.uhn.fhir.model.dstu2.valueset package in 1.5? Is there a substitute that should now be used? This has been a show-stopper for our migration.
Grahame Grieve (Jul 14 2016 at 19:50):
not something that changed in the base spec, so far as I can see, but in the Java code I see:
Grahame Grieve (Jul 14 2016 at 19:50):
org.hl7.fhir.dstu2.model.valuesets.ContractType
Anthony Sute (Jul 15 2016 at 02:00):
Thanks, @Grahame Grieve we using ca.uhn.fhir.model.dstu2.resource.Contract provided by HAPI FHIR (thanks to @James Agnew ) but the DSTU2 Contract resource has change completely from version HAPI 1.4 to HAPI 1.5 - not backwards compatible,a wholesale restructuring of Contract? For instance the Contract.type (e.g. "disclosure") is now gone in HAPI 1.5 of the DSTU2 Version of Contract (we are using it for authorization to disclose aka privacy conset). Any ideas what may be going on here?
http://hapifhir.io/apidocs-dstu2/ca/uhn/fhir/model/dstu2/resource/Contract.html
Lloyd McKenzie (Jul 15 2016 at 03:38):
All of the financial resources were FMM 0 in DSTU 2 - i.e. "draft - not stable, ready for production or even necessarily complete". So significant change isn't necessarily a surprise, or at least shouldn't be. In STU 3, it looks like Consent will be its own stand-alone resource. There's been a very significant amount of work in that space over the past month.
Grahame Grieve (Jul 15 2016 at 03:39):
changes in STU3 don't explain changs in HAPI for DSTU 2 -> DSTU 2 between releases
Lloyd McKenzie (Jul 15 2016 at 03:41):
Isn't HAPI 1.5 the pre-STU 3 release?
Grahame Grieve (Jul 15 2016 at 03:46):
HAPI releases cross versions - HAPI includes support for all versions going forward
Anthony Sute (Jul 16 2016 at 18:54):
Since our DSTU2 resource changed inadvertently (which I understand from this dialogue was not intentional, thank for the clarification) it would useful to deprecate before removing a field/method before removing it or at lest record this change in the release note, We had no idea we would not be able to upgrade. I would make our job easier to upgrade our lib version.I'll add this item to the HAPI tracker and it becomes available again - it's down now.
James Agnew (Jul 20 2016 at 01:39):
Hi @Anthony Sute (sorry for the slow reply) yes, that Enum was indeed removed.
The reason is that we decided to remove generated enums for codeableconcept fields with a binding strength of "example" because they were very misleading. People were interpreting them as being the only allowable values and reporting bugs about how it was cumbersome to use other codes. Unfortunatley this means that if you happen to be using one of the two codes in that valueset, you need to manually enter them now.
James Agnew (Jul 20 2016 at 01:41):
This was a deliberate breaking change incidentally. We try very hard to avoid these since they do cause people issues I know (sorry about that!).
This one came after a fair bit of consideration- I couldn't find any examples at all of people using example binding enums, and I had loads of examples of people being frustrated by them.
Anthony Sute (Jul 20 2016 at 02:34):
Thanks, @James Agnew, the refactoring of "example" binding makes sense and we will refactor our code accordingly. The change log for 1..5 did not mention any changes to our enum class, however. It should have been one of many classes affected by this "example" binding implementation, right?
James Agnew (Jul 20 2016 at 17:40):
Yup. FWIW this was changed per bug #320 and it would affect any example binding field.
Last updated: Apr 12 2022 at 19:14 UTC
