Objectbox-java: DbException for mismatching UID

Created on 21 Mar 2017  Â·  10Comments  Â·  Source: objectbox/objectbox-java

I added ObjectBox to our project and pushed to master. Another contributor added his code and merged it with master. I pulled it again and run now into the following problem (he did not changed code on ObjectBox):

java.lang.RuntimeException: Unable to create application no.ntnu.tdt4240.geoquiz9000.App: io.objectbox.exception.DbException: Incoming entity ID 1:2501900967712254997 does not match existing UID 4549294657536897732 at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4731) at android.app.ActivityThread.-wrap1(ActivityThread.java) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1415) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:148) at android.app.ActivityThread.main(ActivityThread.java:5443) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:728) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618) Caused by: io.objectbox.exception.DbException: Incoming entity ID 1:2501900967712254997 does not match existing UID 4549294657536897732 at io.objectbox.BoxStore.nativeCreate(Native Method) at io.objectbox.BoxStore.<init>(BoxStore.java:201) at io.objectbox.BoxStoreBuilder.build(BoxStoreBuilder.java:157) at no.ntnu.tdt4240.geoquiz9000.App.onCreate(App.java:16) at android.app.Instrumentation.callApplicationOnCreate(Instrumentation.java:1036) at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4728) at android.app.ActivityThread.-wrap1(ActivityThread.java)  at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1415)  at android.os.Handler.dispatchMessage(Handler.java:102)  at android.os.Looper.loop(Looper.java:148)  at android.app.ActivityThread.main(ActivityThread.java:5443)  at java.lang.reflect.Method.invoke(Native Method)  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:728)  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:618)

more info required

Most helpful comment

@greenrobot : thanks for the nuke instructions. I did that several times to no avail.

Then I remembered that android:allowBackup="true"'s favorite job is to restore a buggy database file before the first start even after an uninstall. Set to false during development!

All 10 comments

I have a similar case where removing the @Generated methods, uninstalling the app on the device and even removing the default.json file doesn't do anything.

In case you didn't clear the app data, please do so (as seen in the FAQ):

DbException after switching git branch
You might get an exception like “DbException DB’s last entity ID 4 is higher than 3 from model” after switching back from a feature branch. This is expected. Let’s say you created a new entity on the feature branch and ran your app on the device. This will update the ObjectBox database on the device. ObjectBox keeps track of entity types internally (stores meta info). Now, when you return to your master branch, ObjectBox notices that new entity from the feature branch is missing. In other words, the database is on a newer version than the code. In general, this is a problematic scenario. For similar reasons, you can not downgrade apps via Google Play in general. It’s like time traveling to the future and going back. Thus, it is advised to clear the database to ensure all “data from the future” is gone.

But maybe you did all of this and your app still crashes. That's my case.

I uninstalled the app and then it worked for me. Will keep this issue open until someone solved your problem.

@alexander-fischer Can you give some info what you and the other dev did? E.g. "you added entity A,B, C. Other dev also added entity C plus D"

I put together some info about this topic: http://greenrobot.org/objectbox/documentation/meta-model-ids-uids/
If you had a situation that did not match the expected behavior, please let us know.

What about an option that is deleting and creating an new file if such a exception is happening.

@FabianTerhorst I don't consider the nuke option preferable. Rather, we want to make conflict resolution more intelligent in the future, e.g. suggesting likely changes.

@greenrobot : thanks for the nuke instructions. I did that several times to no avail.

Then I remembered that android:allowBackup="true"'s favorite job is to restore a buggy database file before the first start even after an uninstall. Set to false during development!

@BenoitDuffez Good point, will add this to the docs.

Other than that: if there is no real problem report here, I will close this issue.

I'm not OP, but that would be fine for me, as someone who had the exact same issue.

Issue can be closed then.

Was this page helpful?
0 / 5 - 0 ratings