The Query objects represent a query to be executed at a later time. This is the main way of implementing paging for applications using the media library

Accessors

A query is represented by the IQuery interface which only exposes a few public accessors:

• count() will count the number of elements returned
• all() returns all the entities returned by the database, regardless of how much there are.
• items( nbItems, offset ) returns a subset of the results, consisting of nbItems items, starting at the provided offset

Construction

From the public point of view, the Query objects are read only, and are to be instantiated by the media library itself.

The interface is implemented by 2 possible classes:

• SqliteQuery which implements the main case, and generates a request fetching the results or counting the item depending on which function the user calls
• SqliteQueryWithCount which needs a listing request, and a dedicated count request. This is usefull when the request performs many joins in order to sort the entities, which are not needed when counting.

Choosing between the 2 implementations is up to the developer, there is no dispatching depending on the request.

Both classes can be instantiated using the make_query and make_query_with_count factories.

Limitations

The IQuery interface currently enforces the listing function return type to be a std::vector<std::shared_ptr<T>>, meaning that there currently isn't a way to return a vector of small trivial object, and a shared_ptr will be instantiated every time.

The sqlite implementation of those interfaces are assuming that the entity type is a class that inherits the DatabaseHelpers<T> helper type, causing it not to be usable for short lived objects or arbitrary requests that do not return a class inheriting DatabaseHelpers<T>