Fixed
Status Update
Comments
el...@google.com <el...@google.com>
ap...@google.com <ap...@google.com> #2
Hey - Can you share more about your use-case? Is it because you don't know the schema and are pragmatically retrieving data out of the database? Usually applications know the schemas in their database and in general SQLite is very 'loose' on types, i.e. even if an integer is in the column one can read it as a text, see
da...@google.com <da...@google.com>
pr...@google.com <pr...@google.com> #3
Hey, yes I know about loose typing, it is the reason I need to know the type. And yes, it is because I work with unpredictable schemas and queries, so return value is not known ahead of time.
The workaround is to call getText() always, but I can't then format numbers using user locale, another problem are binary data.
The implementation is there in native driver, it is just private. What I ask for is make it public (add it to interface) and maybe expose sqlite type constants, but it is not required and easy to workaround.
Here is screenshot from another database viewer (written in PHP) to have better idea about the use case:https://www.adminer.org/static/screenshots/select.png
Edit: the getColumnType() is used in isNull() method.
The workaround is to call getText() always, but I can't then format numbers using user locale, another problem are binary data.
The implementation is there in native driver, it is just private. What I ask for is make it public (add it to interface) and maybe expose sqlite type constants, but it is not required and easy to workaround.
Here is screenshot from another database viewer (written in PHP) to have better idea about the use case:
Edit: the getColumnType() is used in isNull() method.
Description
Component used: room-runtime Version used: 2.5.1 Devices/Android versions reproduced on: N/A
After upgrading a project from Room 2.4.2 to 2.5.1, I noticed a new compilation failure when setting a minimal repro project where the first and second commits compare room 2.4.2 and 2.5.1. My theory is below.
QueryCallback
on our Room database. Since this upgrade moved us to a Room version written in Kotlin for the first time, I have a theory about the cause. I've also added aWe had been using a lambda for our callback, along the lines of:
This worked, presumably, because the compiler performed a single-abstract-method (SAM) conversion and treated the lambda expression as an implementation of
QueryCallback.onQuery
.Following the Room upgrade to Kotlin for its own code, I believe this conversion no longer occurs. Kotlin supports SAM conversions for Kotlin interfaces , but they must be declared as .
fun interface Foo
rather than justinterface Foo
. As of 2.5.2,QueryCallback
is just aninterface
This isn't blocking, strictly. We can instead construct an object implementing
QueryCallback
in place of the lambda:But in addition to being more verbose, I found I had to add a
-Xjvm-default=enable
compiler flag to our project so that the interface implementation would compile. Ideally we'd be able to continue relying on SAM conversion and write a lambda instead.