Amplify-android: "E/SQLiteLog: (1) no such table: " occurs when I use "Amplify.DataStore.save()"

[Shumpei0706]

Hi, I am facing an error again and again when I change my GraphQL schema very slightly from tutorial:

"E/SQLiteLog: (1) no such table: "

I only changed the name of the model from Todo to Tod. I tried to check many cases, but even this small change can cause this error.

Am I supposed to register the schema when it's changed, in addition to running modelgen?

[jamesonwilliams]

Do I supposed to register the schema when it's changed in addition to run "modelgen"?

Hi @Shumpei0706 -- yes, if you change the structure/names of the models, you should re-run code generation, and push your changes to the backend, as well.

[woutermilants]

I'm having the same issue.
So first run modelgen and then amplify push ? I did that but still it complains about no such table

My schema is created in AWS, but locally it still fails

[AntonPolkanov]

I am getting the same error (_"E/SQLiteLog: (1) no such table"_), but in a slightly different use case.

I did the getting started tutorial https://docs.amplify.aws/start/q/integration/android and everything worked fine. Then I

1. added a new type Comment to the gql schema
2. ran modelgen
3. ran the application
   and got "E/SQLiteLog: (1) no such table: Comment" error.

Current schema:

enum Priority {
  LOW
  NORMAL
  HIGH
}

type Comment @model {
  id: ID!
  content: String
}

type Todo @model {
  id: ID!
  name: String!
  priority: Priority
  description: String
}

If I delete the Comment type from the schema and do steps (2) and (3) the error goes away.

UPDATE:
I fixed this problem by manualy deleting the app through "Settings->Apps". Then the app successfully ran.
Addition of another new entity to the schema causes the error again. I have no idea why I should delete my app each time I change my schema. Can someone please explain why is it so?

[jamesonwilliams]

The intended behavior of the system is as follows.

__On the development machine, at build time:__ Every set of model schema gets a unique hash. If any of the model schema change, the hash changes.

__On the Android device, at run time:__ If there is no hash in the database, the current model schema hash is stored. If there is a hash in the database, it is compared against the current model schema hash. If they are different, the old database is dropped, and a new one is created, to accommodate the new schema. If the hashes are the same, nothing happens.

It sounds to me like there is a bug, and the system is not correctly re-establishing the database, when the model hash changes.

In theory we have a test for this scenario, here. It may be too low level to catch the current bug.

[jamesonwilliams]

I have no idea why I should delete my app each time I change my schema. Can someone please explain why is it so?

@AntonPolkanov You shouldn't have to. I think it's a bug.

[Shumpei0706]

I am glad to have the same understanding about the issue.

I tried to delete my app and found it worked, I mean my modified schema worked.

I hope this issue resolve.

[sunithapremjee]

I changed my schema.graphql table name from Kospetdata to KospetdataUnit. Next, I ran the modelgen task, rebuilt the app, and did amplifypush. I deleted the app on my phone and reinstalled the app. But still I get SQLiteLog: (1) no such table: KospetdataUnit. Please direct me if I miss any configuration ASAP.

Above issue occurs on Android 10 device. Android 8 device gives following exception and app crashes...

java.lang.RuntimeException: java.util.concurrent.TimeoutException: The source did not signal an event for 5000 milliseconds and has been terminated.
        at io.reactivex.internal.util.ExceptionHelper.wrapOrThrow(ExceptionHelper.java:46)
        at io.reactivex.internal.observers.BlockingMultiObserver.blockingGetError(BlockingMultiObserver.java:153)
        at io.reactivex.Completable.blockingGet(Completable.java:1302)
        at com.amplifyframework.datastore.AWSDataStorePlugin.initialize(AWSDataStorePlugin.java:7)
        at com.amplifyframework.core.category.Category.initialize(Category.java:15)
        at com.amplifyframework.core.Amplify.lambda$beginInitialization$0(Amplify.java:1)
        at com.amplifyframework.core.-$$Lambda$Amplify$EB8h7rBH19uqUcPr0ZtYS0ww0r4.run(Unknown Source:4)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
        at java.lang.Thread.run(Thread.java:764)
     Caused by: java.util.concurrent.TimeoutException: The source did not signal an event for 5000 milliseconds and has been terminated.
        at io.reactivex.internal.observers.BlockingMultiObserver.blockingGetError(BlockingMultiObserver.java:153) 
        at io.reactivex.Completable.blockingGet(Completable.java:1302) 
        at com.amplifyframework.datastore.AWSDataStorePlugin.initialize(AWSDataStorePlugin.java:7) 
        at com.amplifyframework.core.category.Category.initialize(Category.java:15) 
        at com.amplifyframework.core.Amplify.lambda$beginInitialization$0(Amplify.java:1) 
        at com.amplifyframework.core.-$$Lambda$Amplify$EB8h7rBH19uqUcPr0ZtYS0ww0r4.run(Unknown Source:4) 
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) 
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) 
        at java.lang.Thread.run(Thread.java:764) 

On Android 8 device I could sign in, add data to DataStore, and it successfully synced to the cloud, the first time. But when I open the app next time, upon calling Amplify.Auth.fetchAuthSession, result.isSignedIn() is true and the app crashes due to:

java.lang.RuntimeException: java.util.concurrent.TimeoutException: The source did not signal an event for 5000 milliseconds and has been terminated.

On Android 10 device, first time I open the app I see:

SQLiteLog :no such table

Please tell me if I should create a new project and do all configuration one more time.

Below is the autogenerated @Model class KospetdataUnit function hashCode() which doesn't include .append("newtablename") which is the only change I made in my Schema. The table name changed from Kospetdata to KospetDataUnit. All other fields remains the same. So the hashCode seems to remain the same in this case. Please correct me if I am wrong.

 @Override
   public int hashCode() {
    return new StringBuilder()
      .append(getId())
      .append(getTitle())
      .append(getDescription())
      .append(getAudiopath())
      .append(getSensitivity())
      .append(getTimer())
      .toString()
      .hashCode();
  }

[jamesonwilliams]

@sunithapremjee @Shumpei0706 @AntonPolkanov @woutermilants -- what is the output of this command, before and after you update the model?

cat app/src/main/java/com/amplifyframework/datastore/generated/model/AmplifyModelProvider.java

I'm wondering if the contents of that file is _not_ actually changing, after the update?

If it _isn't_, try updating the models on the command line with amplify codegen model, instead of by using the Gradle plugin.

It's critical that AmplifyModelProvider.java contains a new, distinct value in its AMPLIFY_MODEL_VERSION constant.

[sunithapremjee]

I changed the Model name from KospetdataUnit to KospetUnit.Ran modelgen.

Yes AMPLIFY_MODEL_VERSION in AmplifyModelProvider.java now shows a new distinct value.

[rjuliano]

Adding steps to reproduce behavior for reference:

• Given an existing Amplify ModelProvider with AMPLIFY_MODELS_VERSION=123 that is currently being consumed by an app via the AWSDataStorePlugin.
• Modify the schema and add a new type called House for example.
• Regenerate the models. That should generate a new hash for the ModelProvider. AMPLIFY_MODELS_VERSION=456 for example.
• Reload the app.

The app attempts to initialize the storage adapter using AMPLIFY_MODELS_VERSION=456. As part of this process, when calling getInsertSqlPreparedStatements, we get an exception because the underlying db doesn't have the table for the new type (evidently, the table has to be in the database for us to be able to prepare these statements). Because of the exception, we never get to the point where we do the model updates.

I have created a branch where I updated the unit test to reflect this use case. The previous version of the test was just simulating a change in hash, but the schemas themselves were the same, so it didn't catch this use case.

Kind of a chicken and the egg thing. We have to read the model version from the database, to see if we need to update the schema. In order to do that, we need initialize the storage adapter. To initialize the storage adapter, you need the updated schema in place. Maybe we need to separate "System" tables from application tables.

[raphkim]

The app attempts to initialize the storage adapter using AMPLIFY_MODELS_VERSION=456. As part of this process, when calling getInsertSqlPreparedStatements, we get an exception because the underlying db doesn't have the table for the new type (evidently, the table has to be in the database for us to be able to prepare these statements). Because of the exception, we never get to the point where we do the model updates.

718 addresses the above concern by simply removing the statement caching.

Ever since this little optimization logic was added, we were skeptical about how much performance boost we are actually getting out of it. However, now that it got to a point where it is introducing new bugs, it became pretty clear that the minute optimization simply isn't worth the effort.

[rjuliano]

Included in version 1.1.3