Spring Data JDBC и генерация ID

Обратите внимание на JOOQ в следующий раз. Ноль магии аннотаций, максимум помощи строгой типизации. Вот код, который инсертит и возвращает ID новых строк. Это Котлин, но разницы никакой.

val newIds: List<Long> = dsl.insertInto(TABLE_NAME)
  .columns(COLUMN1, COLUMN2, ...)
  .values(value1, value2, ...)
  .onConflictDoNothing()
  .returning(ID)
  .fetch()
  .map{it[ID]}

К слову, можно возвращать строки целиком, если есть задача сразу же вернуть новые энтити. И классы энтити аннотировать никак не надо.

хочется получать id из соответствующей sequence в базе данных
я ожидал, что настройка генерации поля id в Spring Data JDBC делается такими же настройками стратегии генерации.

Я наверное не понял в чем сложности.
Вот кусок кода в SbpingBoot приложении (аналогичный в без Spring c чистым hibernate).
Работающий кусок
работает и с Oracle и PostgreSQL базой.
Обычный SEQUENCE "CREATE SEQUENCE SBPAY_SEQ.."

Правда не совсем стандартно (вызов hibernate) для Spring.

@Entity
@Table(name = "SBPAY_C2B")
@Setter
@Getter
@ToString
public class C2BTable implements Serializable {

  @Id
  @GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "seq_gen")
  @SequenceGenerator(name = "seq_gen", sequenceName = "SBPAY_SEQ", allocationSize = 1)
  @Column(name = "ID", updatable = false, nullable = false)
  private Long id;
......

@Service
public class C2BTableService {
  @PersistenceContext private EntityManager em;
  @Transactional
  public void save(C2BTable table) {
    if (table.getId() == null) {
      log.trace("save new:" + table);
      em.persist(table);
    } else {
      log.trace("update:" + table);
      em.merge(table);
    }
  }

public record MyEntity

Выглядит как оксюморон в контексте Domain-Driven Design.

DDD различает и противопоставляет объекты-значения (value objects), которые иммутабельны и не имеют идентичности, и сущности (entity), которые могут быть различными при одинаковых значениях полей, и поэтому имеют идентификаторы.

Насколько я понимаю, record в java - это для объектов-значений. У них не может быть идентификатора (у них нет идентичности: 2 record с одинаковыми полями не могут различаться), и нет проблем с его установкой.

Есть ощущение что вы пытаетесь сидеть на двух стульях - с одной стороны хочется чтобы как ORM - Repository, Entity и работа на уровне объектов, а с другой чтоб было видно конкретный sql и писать по-сути его. Если хочется именно sql то для вашей задачи у Connection (https://docs.oracle.com/en/java/javase/19/docs/api/java.sql/java/sql/Connection.html) есть метод prepareStatement(String sql, int autoGeneratedKeys), он похоже что делает то что вам нужно. Подозреваю что все развитые библиотеки-помошники в работе с JDBC вкурсе об этой возможности и скорее всего у них есть более удобный способ утилизировать эти возможности.

Позволю себе небольшой совет - попробуйте сделать пет проект на JPA с чистого листа, используя рекомендуемые сообществом best practice и не пытаясь принести туда привычные вам наработки в виде кастомных sequence и record в виде entity.
Это позволит продвинуться дальше и понять, к примеру, что entity по задумке фреймворка мутабельный объект и генерация ID это еще малая беда. Дальше можно словить проблемы с Lazy Loading, апдейту связей итд.

Этим всем конечно можно не пользоваться, но тогда встает вопрос нужен ли вам этот JPA.

Я вот им пользуюсь много лет в проде, но до сих пор для себя не ответил однозначно на этот вопрос.

В postgres можно делая INSERT вернуть значение последовательности:

@Data
@Accessors(chain = true)
public static class Note {
    private Long id;
    private String data;
}

public Note save(Note entity) {
    var sql = """
            INSERT INTO notes (id, data)
            VALUES (default, :data)
            RETURNING id
            """;
    var params = new MapSqlParameterSource().addValue("data", entity.getData());
    return namedParameterJdbcTemplate.query(sql, params, x -> {
        if (x.next()) {
            entity.setId(x.getLong("id"));
        }
        return entity;
    });
}

Таким образом, сделать все за один запрос.
Если необходим батч, то прийдется заранее получить IDки:

SELECT nextval('notes_id_seq') FROM generate_series(1, :size)

Извините, но я никак не пойму в чём у вас проблема. В соответствии с документацией, для авто-инкрементных полей не нужно писать дополнительного кода вообще. У вас ведь Postgres, почему вы не можете просто объявить поля соответственно, используя легаси SERIAL или современный GENERATED ... AS IDENTITY?

Сиквенс у вас уже есть, и вы его пытаетесь использовать. А тип SERIAL это просто синтаксический сахар, который создаёт сиквенс и объявляет поле как NOT NULL DEFAULT nextval('seq_name')

Плюс этого в том, что вам не нужно делать дополнительный запрос к БД для получения ID.

Можно оптимизировать, как делают многие JPA: сделайте SQL sequence сразу с шагом 10, и кешируйте промежуточные значения. Однако, в этом случае могут появляться "дырки" и будет нарушен порядок по Id в случае нескольких инстансов.

Почему бы просто не использовать UUID и генерировать его прямо на клиенте? Или, если хочется последовательные id, то можно и ULID.

а какую БД используете? и наскольког Legacy?

default nextval('seq') для id должно бы помочь, если используете sequence.