IssueTracker

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

  The following changes were cherrypicked through Coastguard (https://android-build.googleplex.com/coastguard/)
  Release Track: (https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
  Created: 2019-10-14 17:23:42.610596+00:00
  Changes: aosp/1123258
 

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

SqlDelight has similar issue https://github.com/square/sqldelight/issues/555

We have the same issue, it'll be nice if we can have something like that

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();
```

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

Any Updates on this ??

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.

Sorry, no updates on this yet and it is not high priority right now.

Any updates? Workarounds are ugly

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.

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..

Can you share some code please. Thanks and happy new year
On Dec 31, 2017 3:53 PM, <buganizer-system@google.com> wrote:

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 from https://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! :)

Thx for sharing. But still I am looking for full dynamic queries :)
On Dec 31, 2017 5:39 PM, <buganizer-system@google.com> wrote:

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..

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.

Thx will check it out
On Dec 31, 2017 6:01 PM, <buganizer-system@google.com> wrote:

see:

https://b.corp.google.com/issues/71458963#comment15

Hmm, that links requires me to login. Can you please verify that it is publicly accessible?

And sorry if I misunderstood this and that link is not for public Access. Thank you.

oh no sorry i just put the wrong link.

here you go:

https://issuetracker.google.com/issues/71458963#comment15

Is paging supported properly too?

In regards to https://issuetracker.google.com/issues/62169706 - why isn't this a compilation error from the @Query annotation processor?