Fixed
Status Update
Comments
da...@google.com <da...@google.com> #2
I'm still working on a fix, but here's the current state of OnConflictStrategy.
# REPLACE
Works as expected. Old rows are replaced.
# IGNORE
Works as expected. New rows are ignored.
# ROLLBACK
This ends the transaction on conflict. Thus, the following call of endTransaction() always fails. This is basically unusable.
# ABORT (default)
As the SQLite doc says, all the changes prior to this statement are preserved, but they are rolled back by the surrounding transaction anyway.
# FAIL
This works pretty much the same as ABORT, except that it does not roll back the current statement at first. It is, however, rolled back by the surrounding transaction along with the preceding changes.
In summary, ABORT and FAIL produce the same results, and unlike the SQLite doc says, they both roll back on conflict (because of the surrounding transaction). ROLLBACK always fails.
# REPLACE
Works as expected. Old rows are replaced.
# IGNORE
Works as expected. New rows are ignored.
# ROLLBACK
This ends the transaction on conflict. Thus, the following call of endTransaction() always fails. This is basically unusable.
# ABORT (default)
As the SQLite doc says, all the changes prior to this statement are preserved, but they are rolled back by the surrounding transaction anyway.
# FAIL
This works pretty much the same as ABORT, except that it does not roll back the current statement at first. It is, however, rolled back by the surrounding transaction along with the preceding changes.
In summary, ABORT and FAIL produce the same results, and unlike the SQLite doc says, they both roll back on conflict (because of the surrounding transaction). ROLLBACK always fails.
ap...@google.com <ap...@google.com> #3
Yes, this is exactly what I observed. It seems that FAIL and ROLLBACK strategies don't make much sense for Room. If this is correct, maybe you should deprecate and later remove them to avoid confusion?
Description
Component used: Fragment Version used: Devices/Android versions reproduced on:
When using Hilt Jetpack integration, the Hilt Work factory failed to create Worker with the following exception:
It appears this is due to a but in the class name mapping.
I declared my worker inside a Kotlin object like this:
Which create a
com.example.webservices.Device.Worker
entry in the Worker Factory mapping. But this entry do not match the real runtime class name which iscom.example.webservices.Device$Worker