Query
  public
  
  
  abstract
  @interface
  Query
  
  
      implements
      
        Annotation
      
  
  
| android.arch.persistence.room.Query | 
Marks a method in a Dao annotated class as a query method.
 
The value of the annotation includes the query that will be run when this method is called. This query is verified at compile time by Room to ensure that it compiles fine against the database.
 The arguments of the method will be bound to the bind arguments in the SQL statement. See
  
 Room only supports named bind parameter  
 Room will automatically bind the parameters of the method into the bind arguments. This is done
 by matching the name of the parameters to the name of the bind arguments.
  
 As an extension over SQLite bind arguments, Room supports binding a list of parameters to the
 query. At runtime, Room will build the correct query to have matching number of bind arguments
 depending on the number of items in the method parameter.
  
 There are 3 types of queries supported in  
 For SELECT queries, Room will infer the result contents from the method's return type and
 generate the code that will automatically convert the query result into the method's return
 type. For single result queries, the return type can be any java object. For queries that return
 multiple values, you can use  
 RxJava2 If you are using RxJava2, you can also return  
 Both  
 UPDATE or DELETE queries can return  
 You can return arbitrary POJOs from your query methods as long as the fields of the POJO match
 the column names in the query result.
 For example, if you have class:
 :name to avoid any confusion between the
 method parameters and the query bind parameters.
 
     @Query("SELECT * FROM user WHERE user_name LIKE :name AND last_name LIKE :last")
     public abstract List<User> findUsersByNameAndLastName(String name, String last);
 
     @Query("SELECT * FROM user WHERE uid IN(:userIds)")
     public abstract ListuserIds is an array of 3 elements, Room will run the
 query as: SELECT * FROM user WHERE uid IN(?, ?, ?) and bind each item in the
 userIds array into the statement.
 Query methods: SELECT, UPDATE and DELETE.
 List or Array. In addition to these, any
 query may return Cursor or any query result can be wrapped in
 a LiveData.
 Flowable<T> or
 Publisher<T> from query methods. Since Reactive Streams does not allow null, if
 the query returns a nullable type, it will not dispatch anything if the value is null
 (like fetching an Entity row that does not exist).
 You can return Flowable<T[]> or Flowable<List<T>> to workaround this limitation.
 Flowable<T> and Publisher<T> will observe the database for changes and
 re-dispatch if data changes. If you want to query the database without observing changes, you can
 use Maybe<T> or Single<T>. If a Single<T> query returns null,
 Room will throw
 EmptyResultSetException.
 void or int. If it is an int,
 the value is the number of rows affected by this query.
 
 class UserName {
     public String name;
     @ColumnInfo(name = "last_name")
     public String lastName;
 }
 
     @Query("SELECT last_name, name FROM user WHERE uid = :userId LIMIT 1")
     public abstract UserName findOneUserName(int userId);
 UserName object. If there is a mismatch between the query result and the fields of the
 POJO, as long as there is at least 1 field match, Room prints a
 CURSOR_MISMATCH warning and sets as many fields as it can.
Summary
| Public methods | |
|---|---|
| 
        
        
        
        
        
        String | 
      value()
      The SQLite query to be run. | 
| Inherited methods | |
|---|---|
Public methods
value
String value ()
The SQLite query to be run.
| Returns | |
|---|---|
| String | The query to be run. | 
- Annotations
- Classes
- Enums
- Exceptions
