Add API to support saving local only resources

[ndegwamartin]

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

Fixes #2123

Description
Clear and concise code change description.
See #2123

Alternative(s) considered
Have you considered any alternatives? And if so, why have you chosen the approach in this PR?
See #2123

Type
Choose one: (Bug fix | Feature | Documentation | Testing | Code health | Builds | Releases | Other)
Feature

Screenshots (if applicable)
N/A

Checklist

• I have read and acknowledged the Code of conduct.
• I have read the Contributing page.
• 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 demo app(s) to verify my change fixes the issue and/or does not break the demo app(s).

[aditya-07]

IMO, adding a default value to FhirEngine.create to specify whether the resources are meant to be local only is a better design choice.

Additionally, we would want all the updates to the resource to be local only as well. Therefore, we should mark the resource as local only in the db itself.

[aditya-07]

Suggested change

	suspend fun create(vararg resource: Resource): List<String>
	/**
	* Creates one or more remote FHIR [resource]s in the local storage without flagging as local
	* changes.
	*/
	suspend fun createRemote(vararg resource: Resource)
	/**
	* Creates one or more FHIR [resource]s in the local storage.
	*
	* @param isLocalOnly - Setting the value to [true] instructs engine that the resource and its subsequent updates should never be synced to the server.
	* @return the logical IDs of the newly created resources.
	*/
	suspend fun create(vararg resource: Resource, isLocalOnly: Boolean = false): List<String>

The default value can be provided in the interface i.e FhirEngine.kt and the FhirEngineImpl.kt would be called with that value if no value is provided by the caller.

[aditya-07]

Suggested change

	override suspend fun createRemote(vararg resource: Resource) {
	return database.insertRemote(*resource)
	}

insertRemote would just add the resource in the db without creating a LocalChange counterintuitively marking the change as local only.

[aditya-07]

Looking at the test, createRemote is doing what it is supposed to do. But, the name createRemote is counterintuitive and suggests that the resource has something to do with the remote server. A more intutive name could have be createLocal ?

[ndegwamartin]

@aditya-07 could you have a second look to see if this is what you had in mind?

[ndegwamartin]

@jingtang10 you had a concern with the updates for the related resources processed by the implementation here, could you share that here or on the ticket #2123 ?

[aditya-07]

Update and Delete changes will still create a LocalChange that maybe synced to the server.

[ndegwamartin]

From this line - ResourceDao.kt#L250 it appears that the database API actually performs an upsert.

[jingtang10]

From this line - ResourceDao.kt#L250 it appears that the database API actually performs an upsert.

what do you mean? why does this matter?

i think we still need to make db change first for this pr to work properly. i.e. creating a new column to indicate local only resources.

[ndegwamartin]

From this line - ResourceDao.kt#L250 it appears that the database API actually performs an upsert.

This was a response to Aditya's comment and feedback from the discussion last time but essentially in the current implementation the API can cater for both Creates and Updates, we'd just need to rename the method to reflect this.

Delete of course would still not be handled hence why we are exploring the db change option to capture all ops.

[joiskash]

Please review the Database Entities, one approach would be to add a boolean field to differentiate between local only and remote. Another idea might be creating a new table to contain local resources.

1. How would existing app migrate to this version? All existing resources could be considered remote.
2. What about changes to local only resources? Can I save a resource as local only and then update it to be synced to server?
3. What would happen to the search APIs? would there be a use case where you would want to only search for local resources vs only remote vs both?

It would be good to get into the use cases and what we would like to support initially. It is not very clear from the issue #2123 as to why this might be needed.
eg: Multiple FHIR servers, to simplify peer to peer sync strategies, save resources that are incomplete eg: a Questionnaire partially filled

[joiskash]

This function is the same as insertRemote, do you think we should handle local changes differently in the DB?

[ellykits]

It would be good to get into the use cases and what we would like to support initially. It is not very clear from the issue #2123 as to why this might be needed.
eg: Multiple FHIR servers, to simplify peer to peer sync strategies, save resources that are incomplete eg: a Questionnaire partially filled

The use case @ndegwamartin was attempting to address is where we'd want to download particular resources from the server (which might have been generated from other sources) to the Android client but prevent the app from uploading any changes made on these resources to the server. For instance Questionnaires, StructureMaps, Binary resource etc as used in OpenSRP.

[ndegwamartin]

Changing this to Draft for now since a workaround solution for the initial problem was put forward