Fixed
Status Update
No update yet.
Comments
yb...@google.com
Is there any hope that this will be looked at any time soon?
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.
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.
mm...@commonsware.com
Hello
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
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
de...@gtempaccount.com
sorry, we are not agianst this feature but it is just not a high priority right now.
You can technically implement this outside room by providing your logging support sqlite open helper.
you can also consider sending a CL ? :)
https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev
You can technically implement this outside room by providing your logging support sqlite open helper.
you can also consider sending a CL ? :)
sk...@gmail.com
be...@google.com
yb...@google.com
ap...@google.com
This is needed for asserting query execution and increasing the speed of adoption of the framework. Please prioritize higher as simple as it is.
Description
Version used: 1.0.0-alpha3
Devices/Android versions reproduced on: n/a
@Relation must return a List<> or Set<>. This includes cases where we know that there should only be one value (e.g., the parent on a 1:N relation). As it stands, we then need to get the 0th entry out of the List or something to get to our one-and-only entity.
IMHO, @Relation should support return types of a single entity instance. If the query returns 2+ rows, I can see three possible responses:
- Throw an exception
- Return the first row's entity
- Either, configurable via an annotation property (and ideally configurable based on build type, as we might throw the exception on debug builds but stagger along with boffo results in production)
After all, in principle, we should have the exact same code ourselves to deal with the current collection-based response.
I'm uncertain how popular @Relation will turn out to be, so I certainly can't characterize this as especially important. I'm just putting it out there for tracking purposes.
Thanks!