Fixed
Status Update
No update yet.
Comments
au...@google.com
el...@google.com
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.
aa...@gmail.com
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?
el...@google.com
mr...@crossway.org
Fine!
Maybe it would also be useful to mention in the docs which strategies can throw an SQLiteConstraintException (btw, is it the only possible type of exception?) and which cannot.
Maybe it would also be useful to mention in the docs which strategies can throw an SQLiteConstraintException (btw, is it the only possible type of exception?) and which cannot.
mr...@crossway.org
SQLiteConstraintException is the only type thrown by the platform SQLite, but if you use custom implementation [1], it might throw something else.
[1]:https://developer.android.com/reference/android/arch/persistence/room/RoomDatabase.Builder.html#openHelperFactory(android.arch.persistence.db.SupportSQLiteOpenHelper.Factory)
[1]:
Description
Artifact used : Room Version used: 2.4.0-alpha05 Devices/Android versions reproduced on: Emulator
This is more of a feature request, but trying out the new multimap feature I'm having issues with LEFT JOIN queries.
Take this example from the release notes (One-to-Many relationship):
Let's say we want all artists, regardless if they have any albums. So we change the query to use a LEFT JOIN:
This won't work if we have an
Artistwithout albums, ifAlbumdoesn't have any nullable fields. Because the current implementation will always try and generate an Album object.Is it possible to let Room return an empty list of 'Albums' in that case? Or
Map<Artist, List<Album>?>?Thanks for your time!