Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using a custom TransformSupportServices for StructureMap-based extraction #712

Merged

Conversation

ekigamba
Copy link
Contributor

@ekigamba ekigamba commented Aug 16, 2021

IMPORTANT: All PRs must be linked to an issue (except for extremely trivial and straightforward changes).

Allow using a custom TransformSupportServices for StructureMap. When using StructureMap-based extraction, we use the command create('ResourceType') to generate new instances of resources. The current implementation lacks support for internal/embedded model types eg RiskAssessment.Prediction, Immunization.Reaction. Here is the usage https://github.com/opensrp/fhircore/blob/issue/403-refactor-extraction-code/android/engine/src/main/java/org/smartregister/fhircore/engine/helper/TransformSupportServices.kt#L50

Description
Add an optional TransformSupportServices param to the ResourceMapper#extract method and ResourceMapper#extractByStructureMap

Alternative(s) considered
Yes, adding support for the internal models inside the datacapture module. This would take longer to implement because the number of models lacking support is not clear. Adding support for an internal models would also require making changes to android-fhir.

Type
Choose one: Feature

Checklist

  • I have read and acknowledged the Code of conduct
  • I have read How to Contribute
  • I have read the Developer's guide
  • I have signed the Google Individual CLA, or I am covered by my company's Corporate CLA
  • I have discussed my proposed solution with code owners in the linked issue(s) and we have agreed upon the general approach
  • I have run ./gradlew spotlessApply and ./gradlew spotlessCheck to check my code follows the style guide of this project
  • I have run ./gradlew check and ./gradlew connectedCheck to test my changes locally
  • I have built and run the reference app(s) to verify my change fixes the issue and/or does not break the reference app(s)

@ekigamba ekigamba force-pushed the ek/resource-mapper-adding-custom-transform-support-services branch from 295e871 to 1ad28bb Compare August 16, 2021 07:56
@ekigamba ekigamba self-assigned this Aug 16, 2021
@ekigamba ekigamba changed the title Hotfix: Allow using a custom TransformSupportServices for StructureMap Allow using a custom TransformSupportServices for StructureMap-based extraction Aug 16, 2021
@codecov-commenter
Copy link

codecov-commenter commented Aug 16, 2021

Codecov Report

Merging #712 (8aa3aaa) into master (1ee392e) will increase coverage by 0.03%.
The diff coverage is 82.35%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master     #712      +/-   ##
============================================
+ Coverage     84.53%   84.57%   +0.03%     
- Complexity      646      651       +5     
============================================
  Files           140      140              
  Lines         10488    10494       +6     
  Branches        795      795              
============================================
+ Hits           8866     8875       +9     
+ Misses         1223     1220       -3     
  Partials        399      399              
Impacted Files Coverage Δ
...ogle/android/fhir/datacapture/DataCaptureConfig.kt 83.33% <ø> (ø)
...android/fhir/datacapture/mapping/ResourceMapper.kt 86.73% <75.00%> (-0.25%) ⬇️
...tacapture/mapping/StructureMapExtractionContext.kt 100.00% <100.00%> (ø)
...com/google/android/fhir/datacapture/DataCapture.kt 83.33% <0.00%> (+16.66%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ee392e...8aa3aaa. Read the comment docs.

@ekigamba ekigamba marked this pull request as ready for review August 16, 2021 22:15
@ekigamba ekigamba assigned jingtang10 and unassigned ekigamba Aug 16, 2021
@ekigamba
Copy link
Contributor Author

@jingtang10 Kindly review. This is a small PR that fixes an issue with ResourceMapper extraction using StructureMap-based extraction. The issue came up while trying to implement a StructureMap for patient registration

@Tarun-Bhardwaj Tarun-Bhardwaj added this to In progress in Data capture library via automation Sep 20, 2021
@ekigamba ekigamba removed the request for review from pankajkatoch November 10, 2021 14:17
@ekigamba ekigamba force-pushed the ek/resource-mapper-adding-custom-transform-support-services branch from 0a8111c to 0b1938d Compare November 17, 2021 14:03
@Tarun-Bhardwaj
Copy link

@ekigamba , is there an ETA by when the changes can be committed to make the PR ready for review?

Copy link
Collaborator

@aditya-07 aditya-07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A few comments, otherwise the PR looks good.

else extractByStructureMap(context, questionnaire, questionnaireResponse, structureMapProvider)
else
extractByStructureMap(
context,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since context is also just used for structure map based extraction, maybe it should also be encapsulated inside StructureMapExtractionContext.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

Comment on lines 25 to 26
val structureMapProvider: (suspend (String, IWorkerContext) -> StructureMap?),
val transformSupportServices: StructureMapUtilities.ITransformerServices? = null
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think reversing these would be better for creating StructureMapExtractionContext objects with lambda.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed

iParser.parseResource(QuestionnaireResponse::class.java, questionnaireResponseJson) as
QuestionnaireResponse

val outputs: MutableList<Base> = mutableListOf()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since outputs is not being used anywhere, can it be avoided altogether?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

ekigamba added a commit to opensrp/fhircore that referenced this pull request Feb 2, 2022
- Disable TransformSupportServices required for extraction
- Re-add the validation and optimize the Q & QR copy
- Pass Q and QR as objects to QuestionnaireFragment instead of encoding and decoding again
- Fix breaking changes due to missing PRs google/android-fhir#712 and google/android-fhir#807
Copy link
Collaborator

@jingtang10 jingtang10 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please address aditya's comments.

@ekigamba - thanks for this pr and the good work in creating the tests. i think the knowledge and experience to create structure map from a mapping is pretty lacking in general (i have no idea how to do this). can you please write a little bit of documentation somewhere and we can put it on the wiki?

thanks!

StructureMapUtilities(simpleWorkerContext)
StructureMapUtilities(
simpleWorkerContext,
structureMapExtractionContext.transformSupportServices
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i went into hapi's code for a quick look, can't really figure out what they do in the case of this being null. just to be safe, shouldn't we call different contructors if this is null or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jingtang10 jingtang10 assigned ekigamba and unassigned aditya-07 and jingtang10 Feb 8, 2022
@ekigamba
Copy link
Contributor Author

@jingtang10 I will add some documentation on the conversion

Copy link
Collaborator

@aditya-07 aditya-07 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please check the comment. Apart from that LGTM

Comment on lines 25 to 26
val transformSupportServices: StructureMapUtilities.ITransformerServices? = null,
val context: Context,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Can you please swap these? Context is usually the first param.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Definitely

@ekigamba ekigamba merged commit 6aff204 into master Feb 28, 2022
Data capture library automation moved this from In progress to Done Feb 28, 2022
@ekigamba ekigamba deleted the ek/resource-mapper-adding-custom-transform-support-services branch February 28, 2022 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

None yet

6 participants