Interface SelectSeekStep18<R extends Record,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17,T18>
- All Superinterfaces:
Attachable
,AttachableQueryPart
,AutoCloseable
,FieldLike
,Fields
,Flow.Publisher<R>
,Iterable<R>
,Publisher<R>
,org.reactivestreams.Publisher<R>
,Query
,QueryPart
,ResultQuery<R>
,Select<R>
,SelectCorrelatedSubqueryStep<R>
,SelectFinalStep<R>
,SelectForStep<R>
,SelectForUpdateStep<R>
,SelectLimitStep<R>
,SelectOptionStep<R>
,SelectUnionStep<R>
,Serializable
,Statement
,TableLike<R>
Select
's DSL API when selecting generic
Record
types.
Example:
Its equivalent in jOOQ
-- get all authors' first and last names, and the number
-- of books they've written in German, if they have written
-- more than five books in German in the last three years
-- (from 2011), and sort those authors by last names
-- limiting results to the second and third row
SELECT T_AUTHOR.FIRST_NAME, T_AUTHOR.LAST_NAME, COUNT(*)
FROM T_AUTHOR
JOIN T_BOOK ON T_AUTHOR.ID = T_BOOK.AUTHOR_ID
WHERE T_BOOK.LANGUAGE = 'DE'
AND T_BOOK.PUBLISHED > '2008-01-01'
GROUP BY T_AUTHOR.FIRST_NAME, T_AUTHOR.LAST_NAME
HAVING COUNT(*) > 5
ORDER BY T_AUTHOR.LAST_NAME ASC NULLS FIRST
LIMIT 2
OFFSET 1
FOR UPDATE
OF FIRST_NAME, LAST_NAME
NO WAIT
Refer to the manual for more details
create.select(TAuthor.FIRST_NAME, TAuthor.LAST_NAME, create.count())
.from(T_AUTHOR)
.join(T_BOOK).on(TBook.AUTHOR_ID.equal(TAuthor.ID))
.where(TBook.LANGUAGE.equal("DE"))
.and(TBook.PUBLISHED.greaterThan(parseDate('2008-01-01')))
.groupBy(TAuthor.FIRST_NAME, TAuthor.LAST_NAME)
.having(create.count().greaterThan(5))
.orderBy(TAuthor.LAST_NAME.asc().nullsFirst())
.limit(2)
.offset(1)
.forUpdate()
.of(TAuthor.FIRST_NAME, TAuthor.LAST_NAME)
.noWait();
- Author:
- Lukas Eder
-
Method Summary
Modifier and TypeMethodDescription@NotNull SelectSeekLimitStep<R>
seek(Field<T1> field1, Field<T2> field2, Field<T3> field3, Field<T4> field4, Field<T5> field5, Field<T6> field6, Field<T7> field7, Field<T8> field8, Field<T9> field9, Field<T10> field10, Field<T11> field11, Field<T12> field12, Field<T13> field13, Field<T14> field14, Field<T15> field15, Field<T16> field16, Field<T17> field17, Field<T18> field18)
Add a syntheticSEEK AFTER
clause to the query.@NotNull SelectSeekLimitStep<R>
seek(T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8, T9 t9, T10 t10, T11 t11, T12 t12, T13 t13, T14 t14, T15 t15, T16 t16, T17 t17, T18 t18)
Add a syntheticSEEK AFTER
clause to the query.@NotNull SelectSeekLimitStep<R>
seekAfter(Field<T1> field1, Field<T2> field2, Field<T3> field3, Field<T4> field4, Field<T5> field5, Field<T6> field6, Field<T7> field7, Field<T8> field8, Field<T9> field9, Field<T10> field10, Field<T11> field11, Field<T12> field12, Field<T13> field13, Field<T14> field14, Field<T15> field15, Field<T16> field16, Field<T17> field17, Field<T18> field18)
Add a syntheticSEEK AFTER
clause to the query.@NotNull SelectSeekLimitStep<R>
seekAfter(T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8, T9 t9, T10 t10, T11 t11, T12 t12, T13 t13, T14 t14, T15 t15, T16 t16, T17 t17, T18 t18)
Add a syntheticSEEK AFTER
clause to the query.@NotNull SelectSeekLimitStep<R>
seekBefore(Field<T1> field1, Field<T2> field2, Field<T3> field3, Field<T4> field4, Field<T5> field5, Field<T6> field6, Field<T7> field7, Field<T8> field8, Field<T9> field9, Field<T10> field10, Field<T11> field11, Field<T12> field12, Field<T13> field13, Field<T14> field14, Field<T15> field15, Field<T16> field16, Field<T17> field17, Field<T18> field18)
Deprecated.- [#7461] - SEEK BEFORE is not implemented correctly@NotNull SelectSeekLimitStep<R>
seekBefore(T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8, T9 t9, T10 t10, T11 t11, T12 t12, T13 t13, T14 t14, T15 t15, T16 t16, T17 t17, T18 t18)
Deprecated.- [#7461] - SEEK BEFORE is not implemented correctlyMethods inherited from interface org.jooq.Attachable
attach, configuration, detach
Methods inherited from interface org.jooq.AttachableQueryPart
getBindValues, getParam, getParams, getSQL, getSQL
Methods inherited from interface org.jooq.Fields
dataType, dataType, dataType, dataTypes, field, field, field, field, field, field, field, field, field, field, fields, fields, fields, fields, fields, fieldsRow, fieldStream, indexOf, indexOf, indexOf, type, type, type, types
Methods inherited from interface org.reactivestreams.Publisher
subscribe
Methods inherited from interface org.jooq.Query
cancel, close, execute, executeAsync, executeAsync, isExecutable
Methods inherited from interface org.jooq.ResultQuery
bind, bind, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, coerce, collect, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetch, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAny, fetchAnyArray, fetchAnyInto, fetchAnyInto, fetchAnyMap, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArray, fetchArrays, fetchAsync, fetchAsync, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchGroups, fetchInto, fetchInto, fetchInto, fetchLazy, fetchMany, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMap, fetchMaps, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOne, fetchOneArray, fetchOneInto, fetchOneInto, fetchOneMap, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptional, fetchOptionalArray, fetchOptionalInto, fetchOptionalInto, fetchOptionalMap, fetchResultSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSet, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingle, fetchSingleArray, fetchSingleInto, fetchSingleInto, fetchSingleMap, fetchSize, fetchStream, fetchStreamInto, fetchStreamInto, getRecordType, getResult, intern, intern, intern, intern, iterator, keepStatement, maxRows, poolable, queryTimeout, resultSetConcurrency, resultSetHoldability, resultSetType, spliterator, stream
Methods inherited from interface org.jooq.SelectCorrelatedSubqueryStep
between, between, between, between, betweenSymmetric, betweenSymmetric, betweenSymmetric, betweenSymmetric, compare, compare, compare, eq, eq, eq, equal, equal, equal, ge, ge, ge, greaterOrEqual, greaterOrEqual, greaterOrEqual, greaterThan, greaterThan, greaterThan, gt, gt, gt, in, in, isDistinctFrom, isDistinctFrom, isDistinctFrom, isNotDistinctFrom, isNotDistinctFrom, isNotDistinctFrom, isNotNull, isNull, le, le, le, lessOrEqual, lessOrEqual, lessOrEqual, lessThan, lessThan, lessThan, lt, lt, lt, ne, ne, ne, notBetween, notBetween, notBetween, notBetween, notBetweenSymmetric, notBetweenSymmetric, notBetweenSymmetric, notBetweenSymmetric, notEqual, notEqual, notEqual, notIn, notIn
Methods inherited from interface org.jooq.SelectFinalStep
getQuery
Methods inherited from interface org.jooq.SelectForStep
forJSON, forJSONB, forXML
Methods inherited from interface org.jooq.SelectForUpdateStep
forKeyShare, forNoKeyUpdate, forShare, forUpdate, withCheckOption, withReadOnly
Methods inherited from interface org.jooq.SelectLimitStep
limit, limit, limit, limit, limit, limit, limit, limit, limit, limit, offset, offset, offset
Methods inherited from interface org.jooq.SelectOptionStep
option
Methods inherited from interface org.jooq.SelectUnionStep
except, exceptAll, intersect, intersectAll, union, unionAll
-
Method Details
-
seek
@NotNull @CheckReturnValue @Support @NotNull SelectSeekLimitStep<R> seek(T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8, T9 t9, T10 t10, T11 t11, T12 t12, T13 t13, T14 t14, T15 t15, T16 t16, T17 t17, T18 t18)Add a syntheticSEEK AFTER
clause to the query.The synthetic
SEEK AFTER
clause is an alternative way to specify anOFFSET
, and thus to perform paging in a SQL query. This can be advantageous for two reasons:- The SQL generated from the
SEEK AFTER
clause is a regular predicate, which can be used by query plan optimisers to choose an appropriate index. The SQL standardOFFSET
clause will need to skipN
rows in memory. - The
SEEK AFTER
clause is stable with respect to new data being inserted or data being deleted while paging through pages.
Example:
DSL.using(configuration) .selectFrom(TABLE) .orderBy(ID, CODE) .seek(3, "abc") .fetch();
The above query will render the following SQL statement:
SELECT table.col1, table.col2, ... FROM table WHERE (id, code) > (3, 'abc') ORDER BY id ASC, code ASC
The actual row value expression predicate may be expanded into this equivalent predicate:
WHERE (id > 3) OR (id = 3 AND code > 'abc')
The
SEEK AFTER
method currently does not support seekingNULL
values, or operating withNULLS FIRST
,NULLS LAST
clauses in theORDER BY
clause.- See Also:
- http://use-the-index-luke.com/sql/partial-results/fetch-next-page,
http://blog.jooq.org/2013/10/26/faster-sql-paging-with-jooq-using-the-seek-method,
seekAfter(Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object, Object)
- The SQL generated from the
-
seek
@NotNull @CheckReturnValue @Support @NotNull SelectSeekLimitStep<R> seek(Field<T1> field1, Field<T2> field2, Field<T3> field3, Field<T4> field4, Field<T5> field5, Field<T6> field6, Field<T7> field7, Field<T8> field8, Field<T9> field9, Field<T10> field10, Field<T11> field11, Field<T12> field12, Field<T13> field13, Field<T14> field14, Field<T15> field15, Field<T16> field16, Field<T17> field17, Field<T18> field18)Add a syntheticSEEK AFTER
clause to the query.The synthetic
SEEK AFTER
clause is an alternative way to specify anOFFSET
, and thus to perform paging in a SQL query. This can be advantageous for two reasons:- The SQL generated from the
SEEK AFTER
clause is a regular predicate, which can be used by query plan optimisers to choose an appropriate index. The SQL standardOFFSET
clause will need to skipN
rows in memory. - The
SEEK AFTER
clause is stable with respect to new data being inserted or data being deleted while paging through pages.
Example:
DSL.using(configuration) .selectFrom(TABLE) .orderBy(ID, CODE) .seek(3, "abc") .fetch();
The above query will render the following SQL statement:
SELECT table.col1, table.col2, ... FROM table WHERE (id, code) > (3, 'abc') ORDER BY id ASC, code ASC
The actual row value expression predicate may be expanded into this equivalent predicate:
WHERE (id > 3) OR (id = 3 AND code > 'abc')
The
SEEK AFTER
method currently does not support seekingNULL
values, or operating withNULLS FIRST
,NULLS LAST
clauses in theORDER BY
clause. - The SQL generated from the
-
seekAfter
@NotNull @CheckReturnValue @Support @NotNull SelectSeekLimitStep<R> seekAfter(T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8, T9 t9, T10 t10, T11 t11, T12 t12, T13 t13, T14 t14, T15 t15, T16 t16, T17 t17, T18 t18)Add a syntheticSEEK AFTER
clause to the query.The synthetic
SEEK AFTER
clause is an alternative way to specify anOFFSET
, and thus to perform paging in a SQL query. This can be advantageous for two reasons:- The SQL generated from the
SEEK AFTER
clause is a regular predicate, which can be used by query plan optimisers to choose an appropriate index. The SQL standardOFFSET
clause will need to skipN
rows in memory. - The
SEEK AFTER
clause is stable with respect to new data being inserted or data being deleted while paging through pages.
Example:
DSL.using(configuration) .selectFrom(TABLE) .orderBy(ID, CODE) .seekAfter(3, "abc") .fetch();
The above query will render the following SQL statement:
SELECT table.col1, table.col2, ... FROM table WHERE (id, code) > (3, 'abc') ORDER BY id ASC, code ASC
The actual row value expression predicate may be expanded into this equivalent predicate:
WHERE (id > 3) OR (id = 3 AND code > 'abc')
The
SEEK AFTER
method currently does not support seekingNULL
values, or operating withNULLS FIRST
,NULLS LAST
clauses in theORDER BY
clause. - The SQL generated from the
-
seekAfter
@NotNull @CheckReturnValue @Support @NotNull SelectSeekLimitStep<R> seekAfter(Field<T1> field1, Field<T2> field2, Field<T3> field3, Field<T4> field4, Field<T5> field5, Field<T6> field6, Field<T7> field7, Field<T8> field8, Field<T9> field9, Field<T10> field10, Field<T11> field11, Field<T12> field12, Field<T13> field13, Field<T14> field14, Field<T15> field15, Field<T16> field16, Field<T17> field17, Field<T18> field18)Add a syntheticSEEK AFTER
clause to the query.The synthetic
SEEK AFTER
clause is an alternative way to specify anOFFSET
, and thus to perform paging in a SQL query. This can be advantageous for two reasons:- The SQL generated from the
SEEK AFTER
clause is a regular predicate, which can be used by query plan optimisers to choose an appropriate index. The SQL standardOFFSET
clause will need to skipN
rows in memory. - The
SEEK AFTER
clause is stable with respect to new data being inserted or data being deleted while paging through pages.
Example:
DSL.using(configuration) .selectFrom(TABLE) .orderBy(ID, CODE) .seekAfter(3, "abc") .fetch();
The above query will render the following SQL statement:
SELECT table.col1, table.col2, ... FROM table WHERE (id, code) > (3, 'abc') ORDER BY id ASC, code ASC
The actual row value expression predicate may be expanded into this equivalent predicate:
WHERE (id > 3) OR (id = 3 AND code > 'abc')
The
SEEK AFTER
method currently does not support seekingNULL
values, or operating withNULLS FIRST
,NULLS LAST
clauses in theORDER BY
clause. - The SQL generated from the
-
seekBefore
@Deprecated @NotNull @CheckReturnValue @Support @NotNull SelectSeekLimitStep<R> seekBefore(T1 t1, T2 t2, T3 t3, T4 t4, T5 t5, T6 t6, T7 t7, T8 t8, T9 t9, T10 t10, T11 t11, T12 t12, T13 t13, T14 t14, T15 t15, T16 t16, T17 t17, T18 t18)Deprecated.- [#7461] - SEEK BEFORE is not implemented correctlyAdd a syntheticSEEK BEFORE
clause to the query.The synthetic
SEEK BEFORE
clause is an alternative way to specify anOFFSET
, and thus to perform paging in a SQL query. This can be advantageous for two reasons:- The SQL generated from the
SEEK BEFORE
clause is a regular predicate, which can be used by query plan optimisers to choose an appropriate index. The SQL standardOFFSET
clause will need to skipN
rows in memory. - The
SEEK BEFORE
clause is stable with respect to new data being inserted or data being deleted while paging through pages.
Example:
DSL.using(configuration) .selectFrom(TABLE) .orderBy(ID, CODE) .seekBefore(3, "abc") .fetch();
The above query will render the following SQL statement:
SELECT table.col1, table.col2, ... FROM table WHERE (id, code) < (3, 'abc') ORDER BY id ASC, code ASC
The actual row value expression predicate may be expanded into this equivalent predicate:
WHERE (id < 3) OR (id = 3 AND code < 'abc')
The
SEEK BEFORE
method currently does not support seekingNULL
values, or operating withNULLS FIRST
,NULLS LAST
clauses in theORDER BY
clause. - The SQL generated from the
-
seekBefore
@Deprecated @NotNull @CheckReturnValue @Support @NotNull SelectSeekLimitStep<R> seekBefore(Field<T1> field1, Field<T2> field2, Field<T3> field3, Field<T4> field4, Field<T5> field5, Field<T6> field6, Field<T7> field7, Field<T8> field8, Field<T9> field9, Field<T10> field10, Field<T11> field11, Field<T12> field12, Field<T13> field13, Field<T14> field14, Field<T15> field15, Field<T16> field16, Field<T17> field17, Field<T18> field18)Deprecated.- [#7461] - SEEK BEFORE is not implemented correctlyAdd a syntheticSEEK BEFORE
clause to the query.The synthetic
SEEK BEFORE
clause is an alternative way to specify anOFFSET
, and thus to perform paging in a SQL query. This can be advantageous for two reasons:- The SQL generated from the
SEEK BEFORE
clause is a regular predicate, which can be used by query plan optimisers to choose an appropriate index. The SQL standardOFFSET
clause will need to skipN
rows in memory. - The
SEEK BEFORE
clause is stable with respect to new data being inserted or data being deleted while paging through pages.
Example:
DSL.using(configuration) .selectFrom(TABLE) .orderBy(ID, CODE) .seekBefore(3, "abc") .fetch();
The above query will render the following SQL statement:
SELECT table.col1, table.col2, ... FROM table WHERE (id, code) < (3, 'abc') ORDER BY id ASC, code ASC
The actual row value expression predicate may be expanded into this equivalent predicate:
WHERE (id < 3) OR (id = 3 AND code < 'abc')
The
SEEK BEFORE
method currently does not support seekingNULL
values, or operating withNULLS FIRST
,NULLS LAST
clauses in theORDER BY
clause. - The SQL generated from the
-