Fixed
Status Update
Comments
yb...@google.com <yb...@google.com> #2
Project: platform/frameworks/support
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
https://android-review.googlesource.com/1123258
https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1
Branch: androidx-master-dev
commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019
Change the way to detect mismatch between POJO and query
This fixes cursor mismatch warnings with expandProjection.
Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt
ze...@gmail.com <ze...@gmail.com> #3
du...@gmail.com <du...@gmail.com> #4
Project: platform/frameworks/support
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically ( b/140759491 ).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
https://android-review.googlesource.com/1288456
Branch: androidx-master-dev
commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020
Re-factor how errors are dismissed when query is re-written
This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.
This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.
Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f
M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
ch...@gmail.com <ch...@gmail.com> #6
We have the same issue, it'll be nice if we can have something like that
xi...@gmail.com <xi...@gmail.com> #7
We have the same issue, @see http://greenrobot.org/greendao/documentation//queries/
for example:
```
Query<User> query = userDao.queryBuilder().where(
new StringCondition("_ID IN " +
"(SELECT USER_ID FROM USER_MESSAGE WHERE READ_FLAG = 0)")
).build();
```
for example:
```
Query<User> query = userDao.queryBuilder().where(
new StringCondition("_ID IN " +
"(SELECT USER_ID FROM USER_MESSAGE WHERE READ_FLAG = 0)")
).build();
```
du...@gmail.com <du...@gmail.com> #8
If I am not mistaken, I thought Yigit previously said that they don't want to create a query builder API like in comment #7 above. If that is still true, then adding support for something like: public User find(RoomSQLiteQuery statement) would be more realistic. That way, it is up to the users of the library to deal with the query builder
ze...@gmail.com <ze...@gmail.com> #9
Any Updates on this ??
jo...@gmail.com <jo...@gmail.com> #10
A simple approach would be to have a annotation
```
@DynamicQuery(columns = {id, name, ...}, tables={person, address, ...})
public List<PersonAddress> getPersonAddress(String query, String[] queryArgs);
```
That way we could generate the mapping and attach the table observers. Then users could use whatever query builder they would like.
```
@DynamicQuery(columns = {id, name, ...}, tables={person, address, ...})
public List<PersonAddress> getPersonAddress(String query, String[] queryArgs);
```
That way we could generate the mapping and attach the table observers. Then users could use whatever query builder they would like.
yb...@google.com <yb...@google.com> #11
Sorry, no updates on this yet and it is not high priority right now.
ol...@gmail.com <ol...@gmail.com> #12
Any updates? Workarounds are ugly
am...@gmail.com <am...@gmail.com> #13
I'd like to voice support for this. I invested a lot of time into conversion only to brick wall on the order. `CursorLoader` supported some fairly complex order clauses. To get Room to do the same I'd need 16 individual query methods each 10 lines long and sharing 95% of the query.
[Deleted User] <[Deleted User]> #14
Currently I solved this by using a Transformation as a mediator between multiple queries, which picks appropriate query based on Transformation input, as long all queries return the same data type. Keep the Transformation code inside repository so it keeps your View classes clean..
ze...@gmail.com <ze...@gmail.com> #15
Can you share some code please. Thanks and happy new year
On Dec 31, 2017 3:53 PM, <buganizer-system@google.com> wrote:
On Dec 31, 2017 3:53 PM, <buganizer-system@google.com> wrote:
[Deleted User] <[Deleted User]> #16
The following code loads a list of "Stores" for the visible map region on the Google MapView. The reason I needed dynamic queries is because the WHERE clause is different depending on the exact values of visible region coordinates.
VisibleRegion class is com.google.android.gms.maps.model.VisibleRegion, if you want to look into it, while I based the dynamic queries on the original algorithm fromhttps://developers.google.com/android/reference/com/google/android/gms/maps/model/LatLngBounds.html#contains(com.google.android.gms.maps.model.LatLng)
Here is the code:
private final MutableLiveData<VisibleRegion> visibleRegion = new MutableLiveData<VisibleRegion>();
public final LiveData<List<StoreEntity>> storeLiveData = Transformations.switchMap(visibleRegion, new Function<VisibleRegion, LiveData<List<StoreEntity>>>() {
@Override
public LiveData<List<StoreEntity>> apply(VisibleRegion vr) {
final double swLat = vr.latLngBounds.southwest.latitude;
final double swLng = vr.latLngBounds.southwest.longitude;
final double neLat = vr.latLngBounds.northeast.latitude;
final double neLng = vr.latLngBounds.northeast.longitude;
StoresDao d = Database.getDb().storesDao();
if (swLng <= neLng)
return d.loadStoresSwlngSmallerOrEqual(swLat, swLng, neLat, neLng);
else
return d.loadStoresSwlngLarger(swLat, swLng, neLat, neLng);
}
});
=======================================================
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND :sw_lng <= stores.lng AND stores.lng <= :ne_lng")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngSmallerOrEqual(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND (:sw_lng <= stores.lng OR stores.lng <= :ne_lng)")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngLarger(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
========================================================
That's it. Every time the map moves, I post the new VisibleRegion to "visibleRegion" MutableLiveData.. and you see the rest.
Happy new year! :)
VisibleRegion class is com.google.android.gms.maps.model.VisibleRegion, if you want to look into it, while I based the dynamic queries on the original algorithm from
Here is the code:
private final MutableLiveData<VisibleRegion> visibleRegion = new MutableLiveData<VisibleRegion>();
public final LiveData<List<StoreEntity>> storeLiveData = Transformations.switchMap(visibleRegion, new Function<VisibleRegion, LiveData<List<StoreEntity>>>() {
@Override
public LiveData<List<StoreEntity>> apply(VisibleRegion vr) {
final double swLat = vr.latLngBounds.southwest.latitude;
final double swLng = vr.latLngBounds.southwest.longitude;
final double neLat = vr.latLngBounds.northeast.latitude;
final double neLng = vr.latLngBounds.northeast.longitude;
StoresDao d = Database.getDb().storesDao();
if (swLng <= neLng)
return d.loadStoresSwlngSmallerOrEqual(swLat, swLng, neLat, neLng);
else
return d.loadStoresSwlngLarger(swLat, swLng, neLat, neLng);
}
});
=======================================================
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND :sw_lng <= stores.lng AND stores.lng <= :ne_lng")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngSmallerOrEqual(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
@Query("SELECT * FROM stores WHERE :sw_lat <= stores.lat AND stores.lat <= :ne_lat AND (:sw_lng <= stores.lng OR stores.lng <= :ne_lng)")
public abstract LiveData<List<StoreEntity>> loadStoresSwlngLarger(double sw_lat, double sw_lng, double ne_lat, double ne_lng);
========================================================
That's it. Every time the map moves, I post the new VisibleRegion to "visibleRegion" MutableLiveData.. and you see the rest.
Happy new year! :)
ze...@gmail.com <ze...@gmail.com> #17
Thx for sharing. But still I am looking for full dynamic queries :)
On Dec 31, 2017 5:39 PM, <buganizer-system@google.com> wrote:
On Dec 31, 2017 5:39 PM, <buganizer-system@google.com> wrote:
[Deleted User] <[Deleted User]> #18
Ah well sorry no, this only works if you need to switch between finite amount of queries based on input.. I was mostly giving a suggestion to the guy above who said he needs to manage 16 queries, and how he could more easily solve it..
jo...@gmail.com <jo...@gmail.com> #19
Take a look at https://github.com/jeffdcamp/dbtools-room .
https://github.com/jeffdcamp/dbtools-room/blob/master/app/src/main/kotlin/org/dbtools/sample/roomsqlite/datasource/database/main/foo/FooDao.kt
Shows an example of dynamic queries using this library. It takes three parameters. The query, the tables to observe, and a mapping function to convert from cursor to object.
Shows an example of dynamic queries using this library. It takes three parameters. The query, the tables to observe, and a mapping function to convert from cursor to object.
ze...@gmail.com <ze...@gmail.com> #20
du...@gmail.com <du...@gmail.com> #22
Hmm, that links requires me to login. Can you please verify that it is publicly accessible?
du...@gmail.com <du...@gmail.com> #23
And sorry if I misunderstood this and that link is not for public Access. Thank you.
lo...@gmail.com <lo...@gmail.com> #25
Is paging supported properly too?
to...@gmail.com <to...@gmail.com> #26
In regards to https://issuetracker.google.com/issues/62169706 - why isn't this a compilation error from the @Query annotation processor?
Description
Version used: 1.0.0.aplha1
Devices/Android versions reproduced on: All
- Sample project to trigger the issue.
- A screenrecord or screenshots showing the issue (if UI related).
I would be cool if queries could be dynamic i.e passed as a parameter, something similar to the @url annotation in retrofit 2