IssueTracker

since these are in public API (:/) we need to do this in 1.2

Opening diff shortly

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d576cbdc911cba16638a44fd8223391a90a07ef7
Author: Mike Nakhimovich <digitalbuddha@users.noreply.github.com>
Date:   Tue Aug 11 09:30:34 2020

    [GH] Hide deprecated internal API.
   
    ## Proposed Changes
   
    * `RoomDatabase.java` has protected `mCallbacks` field which is leaking in the API docs, we should @Hide it.
   
    ## Testing
   
    Test: Ran unit tests locally
   
    ## Issues Fixed
   
    Fixes: 76109329
   
    This is an imported pull request from https://github.com/androidx/androidx/pull/61.
   
    Resolves #61
    Github-Pr-Head-Sha: 6440daa3a63752c7f9d5ba2a390248cd85bc634f
    GitOrigin-RevId: fe92d8466a59b44b218b6ca3cbd57dcda17992f7
   
    Change-Id: Id599cdf5b02b32bdae0166266fb7da967598fe92

A       room/runtime/api/current.ignore
M       room/runtime/api/current.txt
M       room/runtime/api/public_plus_experimental_current.txt
M       room/runtime/api/restricted_current.txt
M       room/runtime/src/main/java/androidx/room/RoomDatabase.java

https://android-review.googlesource.com/1396827

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?