Fixed
Status Update
No update yet.
Comments
jo...@google.com
ha...@google.com
We'd also need to trim the ")".
ma...@gmail.com
that would not work because we don't know if the IN statement is a positive one or a negative one.
e.g. the result would be different if it is
NOT IN
vs
IN.
but putting () should just do the right thing. afaik, SQLite accepts empty set.
e.g. the result would be different if it is
NOT IN
vs
IN.
but putting () should just do the right thing. afaik, SQLite accepts empty set.
to...@gmail.com
When I tested empty sets I was getting no results, but let me double check that I didn't goof something.
ap...@google.com
i think that is WAI.
Imagine you have a query like:
@Query("select * from users where uid IN (:uids)")
List<User> getUsersByIds(List<String> uids)
If you call that query w/ an empty list of uids, the expected result should be an empty list of users.
Imagine you have a query like:
@Query("select * from users where uid IN (:uids)")
List<User> getUsersByIds(List<String> uids)
If you call that query w/ an empty list of uids, the expected result should be an empty list of users.
ha...@google.com
Ok, that's what I thought. Normally one would dynamically create that clause if there is something to filter. We can't do that with Room.
In my case the user can filter by four metadata fields. With Room's auto-expansion each becomes effectively two cases (filter on/off). Additionally they can order by four characteristics as well. Since order can't be made dynamic in any way I'm guaranteed 16 query methods right now. Without the ability for dynamic clauses to be dynamically dropped (null/empty) I resorted to writing a code-gen for the code-gen to generate 256 queries.
In my case the user can filter by four metadata fields. With Room's auto-expansion each becomes effectively two cases (filter on/off). Additionally they can order by four characteristics as well. Since order can't be made dynamic in any way I'm guaranteed 16 query methods right now. Without the ability for dynamic clauses to be dynamically dropped (null/empty) I resorted to writing a code-gen for the code-gen to generate 256 queries.
ke...@mercari.com
So is WAI the verdict? As it stands Room is a cute one-trick-pony in the world of ORM (minus the R). Accepting PRs was mentioned in another issue...any chance this source is hitting the interwebs anytime soon?
ha...@google.com
it is WAI as in the example.
requiring you to create 256 queries is definitely not WAI :)
Right now, we have 3 possible paths for dynamic queries:
allow you to pass in SQL, practically opening room for all injection problems + losing verification (of course we can limit it to SQL + params)
create builders (if we can avoid, better)
some 3rd option that does code-gen based on a query. (need to experiment)
I'm not super happy w/ any of these which is partially why the development on this issue is a bit stuck (also, i didn't have much time to focus on it).
any recommendations?
requiring you to create 256 queries is definitely not WAI :)
Right now, we have 3 possible paths for dynamic queries:
allow you to pass in SQL, practically opening room for all injection problems + losing verification (of course we can limit it to SQL + params)
create builders (if we can avoid, better)
some 3rd option that does code-gen based on a query. (need to experiment)
I'm not super happy w/ any of these which is partially why the development on this issue is a bit stuck (also, i didn't have much time to focus on it).
any recommendations?
ka...@mercari.com
So the main reason I migrated to Room was not for query formation. I already did that by hand (in fact a lot of it looks like Room code). The Room annotation process is very slick kudos for that. The real reason I switched was for the life-cycle/cursor management, and the allusion towards solving the CursorWindow overflow woes. I really really really wanted to see if it helped with the window crashes so much so that I rigged my own code-gen.
That said I think Google far too often errs on the side of 'people are too dumb to do it right'. The `people are too dumb` assessment usually holds true, but you should never sacrifice functionality for the lowest common denominator. Apps in Android are sand-boxed for a reason. If a user exposes themselves that's their own foolishness; the fact is they can already do that with raw queries.
<spoiler>I'm no SQL expert</spoiler>
1) In that vein, I'd say allow a means to pass SQL. Maybe an @RawQuery that throws caution to the wind.
2) It might be possible to manage a switch in the annotation and allow transparent method extrapolation:
val a:String queryA = "..." <---. (can be verified!)
\
@Query(WHEN :decisionTree [val A: String] ...) thisFirstParamGivesMeControlOverManyQueries( decisionTree: Int);
3) I don't believe that IN() is ever useful or intended, so dumping that associated clause on null/empty would make the lib infinitely more versatile.
4) I think ORDER BY only has very minor vulnerabilities, so a simple string clause in a pinch should work for now *after* ORDER BY.
That said I think Google far too often errs on the side of 'people are too dumb to do it right'. The `people are too dumb` assessment usually holds true, but you should never sacrifice functionality for the lowest common denominator. Apps in Android are sand-boxed for a reason. If a user exposes themselves that's their own foolishness; the fact is they can already do that with raw queries.
<spoiler>I'm no SQL expert</spoiler>
1) In that vein, I'd say allow a means to pass SQL. Maybe an @RawQuery that throws caution to the wind.
2) It might be possible to manage a switch in the annotation and allow transparent method extrapolation:
val a:String queryA = "..." <---. (can be verified!)
\
@Query(WHEN :decisionTree [val A: String] ...) thisFirstParamGivesMeControlOverManyQueries( decisionTree: Int);
3) I don't believe that IN() is ever useful or intended, so dumping that associated clause on null/empty would make the lib infinitely more versatile.
4) I think ORDER BY only has very minor vulnerabilities, so a simple string clause in a pinch should work for now *after* ORDER BY.
Description
Environment:
Issue Summary:
In Jetpack Compose 1.7, when using the POBox IME on Xperia devices, certain Japanese characters such as small characters (e.g., "っ", "ゃ", "ゅ", "ょ") and diacritic marks (dakuten, handakuten) cannot be input into a
TextField. Additionally, toggle input (e.g., pressing 'あ' multiple times to switch to 'い', 'う', etc.) does not work as expected.Steps to Reproduce or Code Sample to Reproduce:
TextField.For a detailed demonstration of the issue, please refer to the attached reproduction video.
Actual Results:
Expected Results:
Reproduction Rate:
100%
This issue occurs every time under the described conditions.
Environment:
TextFieldis used.Additional Information:
According to our investigation, POBox is pre-installed on Xperia devices up to the Xperia 1, released in 2019 (https://www.sony.jp/xperia/xperia/xperia1/?srsltid=AfmBOoox1BTdp0e7TprBv0hcGsft9wxrpNf_-KepPYoCqf6QgXX6axE1 ). As a result, this issue could affect a significant number of Android users in Japan.
While we suspect the issue may be related to the combination of Xperia devices and POBox, we would greatly appreciate your investigation into a potential solution or workaround within Jetpack Compose.
Workaround Attempted:
As a workaround for this issue, we attempted to directly use
EditTextwithinAndroidViewby utilizingViewBindingin the Compose environment. However, we encountered another issue in our project that prevented us from using this workaround effectively.It would be greatly appreciated if you could also prioritize investigating and addressing this issue. Here is the link to the related issue:
https://partnerissuetracker.corp.google.com/issues/369354336#comment4
Sample App to Reproduce:
https://github.com/yurihondo/screentransitionsample
You can reproduce the issue using this app:
Please especially check the implementation at the following location:
https://github.com/yurihondo/screentransitionsample/blob/c71e4d6f41c76cdeb8a359e3cc6938a5250ac5da/feature/applepie/src/main/java/com/yurihondo/screentransitionsample/applepie/EditRoute.kt#L76