Query<T>. The type argument must be a subclass of
ManagedObject, which determines the table the query will operate on.
Query<T>has four basic execution methods:
fetchwill retrieve data from a database (it is equivalent to the SQL operation
updatewill modify existing data in a database (it is equivalent to the SQL operation
insertwill add new data to a database (it is equivalent to the SQL operation
deletewill remove data from a database (it is equivalent to the SQL operation
Query<T>has many configurable properties. These properties will impact which objects get fetched, the data that gets sent to the database, the order that data is returned in, and so on.
Usermanaged object subclass exists that is declared like so:
Query<T>object, configure its
valuesproperty and then call its
Query<T>is an instance of
T(the managed object type you are inserting). You can configure individual properties of
values, or you can assign
valuesto an instance you have created elsewhere:
valuesobject are included in the SQL INSERT query. In this example, both
idand therefore only
nullwill be sent as
NULL. For example, consider the following
Query<T>and its SQL:
values, or configuring the properties of
values. In an instance you create, a relationship property must be instantiated before accessing its properties. When accessing the relationship properties of
values, an empty instance of the related object is created immediately upon access.
values, it will adopt the behavior of
valuesand instantiate relationships when accessed. Also note that after assigning an object to
values, changes to the original object are not reflected in
values. In other words, the object is copied instead of referenced.
Query<T>is similar to inserting data: you set the
Query.valuesfor properties you want to change. The type parameter for the
Query<T>indicates which database table will get updated when the query is executed.
Query.whereproperty - which gets translated into the where clause of the SQL command. Here's an example:
whereis also the same managed object type the query is being executed on. In the above example, then, both
whereand instances of
User. This query executes the following SQL:
whereproperty is a very powerful and flexible, and so there is an entire section dedicated to it later in this guide. For now, we'll stick to some of the things specific to
insert(), only the values set in the
valuesproperty of a query get updated when executing
update(). Values that are omitted are not included. Values that need to be set to
nullmust explicitly be set to
nullin the query:
updateOnemethod will build and execute a SQL query in the same way a normal
updatedoes, however, it will only return the single instance that was updated instead of a list. This is convenience method for the caller to get back a single instance instead of a list:
updateOnemethod will return
nullif no rows were updated. It is important to note that if
updateOneis used and more than one row is updated,
updateOnewill throw an exception and the changes to the data are not reversible. Because this is likely a mistake, this is considered an error, hence the exception is thrown. It is up to the programmer to recognize whether or not a particular
updateOnequery would impact multiple rows.
Query<T>to do an update without configuring
where, an exception is thrown prior to carrying out the request. If you actually want to update every row of a table, you must set the
trueprior to execution. (This property defaults to
Query<T>will delete rows from a database when using
delete(). Like update queries, you should specify a row or rows using
whereproperties of the
Query<T>. The result of a delete operation will be a
Future<int>with the number of rows deleted.
valuesare ignored when executing a delete.
Query<T>, fetching data is the most configurable. A simple
Query<T>that would fetch every instance of some entity looks like this:
fetchLimitproperty. You may also set the
Query<T>to skip the first
offsetnumber of rows. Between
offset, you can implement naive paging. However, this type of paging suffers from a number of problems and so there is another paging mechanism covered in later sections.
whereproperty to filter the result set, just like delete and update queries. The
valuesof a query are ignored when fetching objects. You may also fetch a single instance with
fetchOne. If no instance is found,
nullis returned. Only use this method when the search criteria is guaranteed to be unique.
ManagedContext.fetchObjectWithID. The method must be able to infer the type of the object, or you must provide it:
sortBymethod of a
Query<T>. Here's an example:
sortBytakes two arguments: a closure that returns which property to sort by and the order of the sort.
Query<T>results can be sorted by multiple properties. When multiple
sortBys are invoked on a
sortBys are used to break ties in previous
sortBys. For example, the following query will sort by last name, then by first name:
(u) => u.lastNamein the previous section is a property selector that selects the last name of a user.
(o) => o.$END$. A downloadable settings configuration for IntelliJ exists here that includes this shortcut.
fetch()), the default properties for each object are fetched. The default properties of a managed object are properties that correspond to a database column - attributes declared in the table definition. A managed object's default properties can be modified when declaring its table definition:
omitByDefaultset to true will not be fetched by default.
omitByDefaultcan still be fetched. Likewise, a property that is in the defaults can still be omitted. Each
returningPropertiesmethod to adjust which properties do get returned from the query. Its usage looks like this:
returningPropertiesis a multiple property selector - instead of returning just one property, it returns a list of properties.
returningProperties, but you may not include 'has-many' or 'has-one' relationships. An exception will be thrown if you attempt to. To include properties from relationships like these, see join in Advanced Queries.
returningProperties, it will automatically be added. The primary key is necessary to transform the rows into instances of their
ValidationException. Both of these exception types have an associated
Responseobject that is sent instead of the default 500 Server error.