Status Update
No update yet.
Comments
yb...@google.com
I find it pretty disappointing that there is no way to debug queries. I am using Room in an application with foreign key relationships, and these are failing silently and for some mysterious reason, and I have no way to debug my queries other than manually adding a bunch of LogCat logs.
Thank you for considering this.
wo...@gmail.com
Room database looks very promising and interesting, But I am still on initial stage of learning it and I am facing the problem of not being able to see log outputs of the database.
While implementing / learning debugging should be enabled.
It would be extremely helpful if we can have debugging logs for Room database implementation.
Thanks and regards
Abhiroop Nandi Ray
tr...@gmail.com
You can technically implement this outside room by providing your logging support sqlite open helper.
you can also consider sending a CL ? :)
yb...@google.com
yb...@google.com
el...@google.com
ap...@google.com
ap...@google.com
ap...@google.com
da...@google.com
xi...@robinhood.com
yb...@google.com
this looks like a perfect candidate for external contribution.
It is also probably better to implement this in the androidx.sqlite package instead to ensure all queries are covered.
yb...@google.com
Branch: androidx-master-dev
commit ab6d205c0217a0ed5c170bf6ceadb20422947699
Author: Elif Bilgin <elifbilgin@google.com>
Date: Tue Nov 17 13:50:26 2020
Implementing functionality for a general callback function for SQLite queries. If possible, bind arguments are provided to the callback in addition to the SQLite query statement. This callback may be used for logging executed queries, in which case it is recommended to use an immediate executor.
This CL will be followed up by a CL resolving
Test: Tests have been added QueryInterceptorTest.kt
Relnote: Add query callback feature to Room.
Bug: 74877608
Change-Id: Iaa513e39115f0c9c68359774fa70e1d3dd022c39
A room/integration-tests/kotlintestapp/src/androidTest/java/androidx/room/integration/kotlintestapp/test/QueryInterceptorTest.kt
M room/runtime/api/current.txt
M room/runtime/api/public_plus_experimental_current.txt
M room/runtime/api/restricted_current.txt
A room/runtime/src/main/java/androidx/room/QueryInterceptorDatabase.java
A room/runtime/src/main/java/androidx/room/QueryInterceptorOpenHelper.java
A room/runtime/src/main/java/androidx/room/QueryInterceptorOpenHelperFactory.java
A room/runtime/src/main/java/androidx/room/QueryInterceptorStatement.java
M room/runtime/src/main/java/androidx/room/RoomDatabase.java
xi...@robinhood.com
enum class Sample {
A_DEFAULT, B
}
If we use Room default type converters, it works great until someday we added new field like
enum class Sample {
A_DEFAULT, B, C
}
and now server returns new enum value of C. We want our app to treat unrecognized values as default value (That's how our own custom enum Type Converter are implemented) but Room default type converters will throw exception in such case and crashing our old clients.
Of course we can always specify our custom Type Converter to @TypeConverters list in room db definition. But our code base is huge so sometimes one random developer forgot to add that and the app still compiles and runs until someday we realized that our DB is not using our custom TypeConverter.
We want to disable default type converters so can our app get compile time error if anyone forgot to add the custom Type Converter to room db definition. Thanks!
yb...@google.com
Makes sense.
We thought about this during design there wasn't a clear way to solve this. e.g. we could require some "defaultValue" annotation on enums for automatic conversion to work but that also break if developer does not own it.
Maybe we'll iterate on this (open to suggestion). Meanwhile, I'll prototype something to disable this with a flag.
yb...@google.com
we are thinking of providing something like
PTAL to see if that seems fine or if you have other suggestions, we are open to it. This feels more scalable than compiler flags that are not discoverable.
xi...@robinhood.com
yb...@google.com
so that is one weird thing we need to resolve.
TypeConverters annotations are scoped such that if you put it on a database , all dao's in that db can use it.
if you put it in a dao, the methods in the dao can use it.
and if you put an entity, only works on that entity.
This is nested as we traverse the code such that @TypeConverters listed in lower layers get priority over higher layers (e.g. a DAO can define how a Date is converted even though there is a different Date converter in the DB)
so coming back to states, inherited makes it just use whatever my parent set so that you can change the state of 1 of the built in converters (e.g. disable enums but keep UUID) w/o affecting other decisions the database made.
Unfortunately, a boolean is not sufficient because we cannot have null as an option in the annotation.
open for suggestions though, not very happy w/ this to be honest.
ap...@google.com
Branch: androidx-main
commit c0811e066e1944ac8319ff5cea8e93f7acd70649
Author: Yigit Boyar <yboyar@google.com>
Date: Wed Sep 08 08:55:09 2021
Add ability to disable built-in converters
This CL adds a new property to the TypeConverters annotation to disable
built in converters in certain scopes. This can be useful when the
developer do not want to use built in converters and rather prefer a
compile time error.
I've also updated XProcessing message assertions to receive a list such
that it can handle cases where multiple messages match the given
message.
Bug: 73132006
Test: BuiltInConverterFlagsTest
Relnote: "We have added a new property to the TypeConverters annotation
to let developers disable built in enum and uuid converters. By default,
these converters are on but you can disable them for a certain scope, or
for the whole database. See TypeConverters documentation for details."
Change-Id: I671e8b1a8eb71d3309da04feaf6f9b18719489fc
M room/room-common/src/test/java/androidx/room/AnnotationRetentionPolicyTest.kt
M room/room-compiler/src/main/kotlin/androidx/room/processor/CustomConverterProcessor.kt
M room/room-compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/room-common/api/current.txt
M room/room-common/api/public_plus_experimental_current.txt
M room/room-compiler/src/main/kotlin/androidx/room/processor/cache/Cache.kt
M room/room-common/src/main/java/androidx/room/TypeConverters.java
A room/room-compiler/src/test/kotlin/androidx/room/solver/BuiltInConverterFlagsTest.kt
M room/room-compiler/src/test/kotlin/androidx/room/solver/BasicColumnTypeAdaptersTest.kt
M room/room-compiler-processing-testing/src/main/java/androidx/room/compiler/processing/util/CompilationResultSubject.kt
A room/room-compiler/src/main/kotlin/androidx/room/vo/BuiltInConverterFlags.kt
M room/room-compiler/src/main/kotlin/androidx/room/processor/Context.kt
A room/room-compiler-processing-testing/src/main/java/androidx/room/compiler/processing/util/DiagnosticMessagesSubject.kt
M room/room-compiler/src/test/kotlin/androidx/room/solver/TypeConverterStoreTest.kt
M room/room-compiler/src/test/kotlin/androidx/room/solver/TypeAdapterStoreTest.kt
D room/room-compiler-processing-testing/src/main/java/androidx/room/compiler/processing/util/DiagnosticMessageSubject.kt
A room/room-common/src/main/java/androidx/room/BuiltInTypeConverters.java
M room/room-common/api/restricted_current.txt
yb...@google.com
#15, the new API has landed and should be available in the next alpha. This is coming a bit hot before beta so please take a look to ensure it fixes your need.
Thanks!
xi...@robinhood.com
From room page,
yb...@google.com
Yes. you can also use a snapshot from androidx.dev (they are fairly stable despite being snapshots)
Description
Therefore I have a long of TypeConverters that convert all my different type of enums.
It would be great if you could add a default type converter for enums.
An implementation that works is to use .name() and valueOf() for serialization / de-serialization.