Module org.jooq
Package org.jooq

Interface SelectSeekStep14<R extends Record,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14>

All Superinterfaces:
Attachable, AttachableQueryPart, FieldLike, FieldOrRowOrSelect, 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>
public interface SelectSeekStep14<R extends Record,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14> extends SelectLimitStep<R>
This type is used for the Select's DSL API when selecting generic Record types.

Example: 


 -- 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
Its equivalent in jOOQ 

 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();
Refer to the manual for more details
Author:
Lukas Eder

  • 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)
      Add a synthetic SEEK AFTER clause to the query.

      The synthetic SEEK AFTER clause is an alternative way to specify an OFFSET, and thus to perform paging in a SQL query. This can be advantageous for two reasons:

      1. 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 standard OFFSET clause will need to skip N rows in memory.
      2. 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 column list length must match the ORDER BY expression list length.

      The SEEK AFTER method currently does not support seeking NULL values, or operating with NULLS FIRST, NULLS LAST clauses in the ORDER BY clause.

      See Also:

    • 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)
      Add a synthetic SEEK AFTER clause to the query.

      The synthetic SEEK AFTER clause is an alternative way to specify an OFFSET, and thus to perform paging in a SQL query. This can be advantageous for two reasons:

      1. 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 standard OFFSET clause will need to skip N rows in memory.
      2. 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 column list length must match the ORDER BY expression list length.

      The SEEK AFTER method currently does not support seeking NULL values, or operating with NULLS FIRST, NULLS LAST clauses in the ORDER BY clause.

      See Also:

    • 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)
      Add a synthetic SEEK AFTER clause to the query.

      The synthetic SEEK AFTER clause is an alternative way to specify an OFFSET, and thus to perform paging in a SQL query. This can be advantageous for two reasons:

      1. 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 standard OFFSET clause will need to skip N rows in memory.
      2. 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 column list length must match the ORDER BY expression list length.

      The SEEK AFTER method currently does not support seeking NULL values, or operating with NULLS FIRST, NULLS LAST clauses in the ORDER BY clause.

      See Also:

    • 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)
      Add a synthetic SEEK AFTER clause to the query.

      The synthetic SEEK AFTER clause is an alternative way to specify an OFFSET, and thus to perform paging in a SQL query. This can be advantageous for two reasons:

      1. 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 standard OFFSET clause will need to skip N rows in memory.
      2. 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 column list length must match the ORDER BY expression list length.

      The SEEK AFTER method currently does not support seeking NULL values, or operating with NULLS FIRST, NULLS LAST clauses in the ORDER BY clause.

      See Also:

    • 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)
      Deprecated.
      - [#7461] - SEEK BEFORE is not implemented correctly
      Add a synthetic SEEK BEFORE clause to the query.

      The synthetic SEEK BEFORE clause is an alternative way to specify an OFFSET, and thus to perform paging in a SQL query. This can be advantageous for two reasons:

      1. 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 standard OFFSET clause will need to skip N rows in memory.
      2. 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 column list length must match the ORDER BY expression list length.

      The SEEK BEFORE method currently does not support seeking NULL values, or operating with NULLS FIRST, NULLS LAST clauses in the ORDER BY clause.

      See Also:

    • 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)
      Deprecated.
      - [#7461] - SEEK BEFORE is not implemented correctly
      Add a synthetic SEEK BEFORE clause to the query.

      The synthetic SEEK BEFORE clause is an alternative way to specify an OFFSET, and thus to perform paging in a SQL query. This can be advantageous for two reasons:

      1. 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 standard OFFSET clause will need to skip N rows in memory.
      2. 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 column list length must match the ORDER BY expression list length.

      The SEEK BEFORE method currently does not support seeking NULL values, or operating with NULLS FIRST, NULLS LAST clauses in the ORDER BY clause.

      See Also: