doSelectByIDs<R> method
FutureOr<List<R> >
doSelectByIDs<R>(
- TransactionOperation op,
- String entityName,
- String table,
- List<
Object> ids, { - int? limit,
- int? offset,
- bool? orderByID,
- OrderDirection? orderDirection,
- PreFinishDBOperation<
List< ? preFinish,Map< , List<String, dynamic> >R> >
override
Ordering and pagination:
limit: the maximum number of returned entities. Also the page size ofpage.offset: the return offset, for pagination.page: the 1-based page to return, an ergonomic alternative tooffset: it resolves to(page - 1) * limit. Requires a positivelimit, and can't be combined withoffset. See resolveSelectOffset.orderByID: iftruethe result is ordered by the table ID column, automatically resolved from the table scheme (TableScheme.idFieldName) or from EntityHandler.idFieldName. Defaults totruewhenoffsetis defined, since a paginated select needs a stable order to be correct, and, with a SQL database, also whenlimitis defined (which rows an unorderedLIMITreturns is undefined). Passfalseto opt out.orderDirection: the OrderDirection of the ordering, OrderDirection.ascending by default. Ignored while the ordering is not active (seeorderByID).
A query over a to-many relationship returns (and counts, and paginates)
each entity once: with a SQL database, its JOINs are in a subquery of
the matching IDs. Note that 2 conditions over the same to-many
relationship (roles.type == "a" && roles.type == "b") are, on SQL,
over the same joined row, and in memory each over any related entity.
Implementation
@override
FutureOr<List<R>> doSelectByIDs<R>(
TransactionOperation op,
String entityName,
String table,
List<Object> ids, {
int? limit,
int? offset,
bool? orderByID,
OrderDirection? orderDirection,
PreFinishDBOperation<List<Map<String, dynamic>>, List<R>>? preFinish,
}) => executeOperation<List<Map<String, dynamic>>, List<R>>(
op,
(conn) => _doSelectByIDsImpl<R>(
table,
ids,
entityName,
limit: limit,
offset: offset,
orderByID: orderByID,
orderDirection: orderDirection,
),
preFinish,
);