Model based APIs for API Category check against existence of DataStore

[lawmicha]

since removing the syncable flag in the models (they weren't being model generated at the moment anyways). and the change to datastore to always treat non-system models as syncable, then API category's Model based APIs are broken. API needs a way to check if DataStore exists, and if it does not, treat the models non-syncable. If datastore exists, developer should use datastore

[lawmicha]

#238 (comment)

[palpatim]

Related to #177

[jamesonwilliams]

API needs a way to check if DataStore exists

Why does API need to know of the existence of DataStore? Shouldn't DataStore depend on API, but API know nothing of DataStore?

[lawmicha]

API needs a way to check if DataStore exists

Why does API need to know of the existence of DataStore? Shouldn't DataStore depend on API, but API know nothing of DataStore?

Right, originally the Model Based API in API plugin had a dependency on ModelRegistry, which then makes it look like API depends on if sync enabled is true which is DataStore's use case. this code has been refactored and no longer checks for sync-enabled. consumers now have to explicitly construct requests which have sync fields or not.

[lawmicha]

i believe this can be closed- Using API's GraphQLRequest builders with APIPlugin directly should be done on an API that does not have conflict resolution enabled. The original issue was opened with the idea that the builders should fail to construct the request if the API does have conflict resolution enabled, but this would have just moved the failure earlier. Instead, we can keep this logic out of the builders and leave it to the request to fail. As such, developers will rarely get into this situation since Amplify CLI will only create the conflict resolution enabled API by asking if the API should be enabled for DataStore.