Привет, есть спорный вопрос, в одной табличке в базе лежат 100 записей, запрос к ним индексированфый, в сек летит примерно 5К месседжей на каждый из которых нужно сходить в эту табличку, есть ли смысл их кэшировать в in memory ? или база сама сделает максимальные оптимизации положит там в кэш свой эти данные и для нее эт не будет проблемой (есть такое мнение)

ну если записей сотка, они не меняются и весят не много - можно кешироавть в рантайме

но стоит ли игра свечь, если бд вернет данные за пару миллисек?

а кол запросов которые она будет обрабатывать ?

>пара миллисек

вообще пахнет преждеврменной оптимизацией, будут проблемы с получением данных из этой таблички, вот реальный затык - будете оптимизировать

Можно сказать что будет -1 коннекшин из пула, который будет постоянно занят этой работой, и вопрос как это отразится на CPU вить запросов будет тьма, я бы сказал постоянно

Это как вместо того что бы использовать пульт от телевизора бегать по старинке к нему и переключать канал )
Вроде бы не напряжно если редко, но с другой стороны когда постоянно то не сильно хочется )))

.

ребят, spring boot, jpa, repository, h2 database, blob поле, кастомный запрос в методе репозитория. каким образом корректно замапить blob на byte[] в кастомном запросе?

  @Query(
      "select a.id, a.businessProcessId, a.transitionCode, a.sent, a.document "+
      "from BusinessProcessPendingDocument a "+
      "   inner join BusinessProcess b on b.id=a.businessProcessId "+
      "      inner join BusinessProcessTransition c on c.businessProcessCode=b.businessProcessCode and c.specificationVersion=b.specificationVersion and c.stateCode = b.stateCode and c.transitionCode = a.transitionCode "+
      ""
      )
  List<BusinessProcessPendingDocument> findReadyToSend();

doc

ument объявлен как:
  @Lob
  @Column(name = "document", columnDefinition = "CLOB")
  private byte[] document;

а как в БД эти данные хранятся через запятую?

если смотреть трейс JPA, то при выполнении генеренного findAll в консоли:

2020-12-11 17:13:18.237 DEBUG 45516 --- [   scheduling-1] org.hibernate.SQL                        : select businesspr0_.id as id1_2_, businesspr0_.business_process_id as business2_2_, businesspr0_.document as document3_2_, businesspr0_.sent as sent4_2_, businesspr0_.transition_code as transiti5_2_ from business_process_pending_document businesspr0_
2020-12-11 17:13:18.251 TRACE 45516 --- [   scheduling-1] o.h.type.descriptor.sql.BasicExtractor   : extracted value ([id1_2_] : [BIGINT]) - [3]
2020-12-11 17:13:18.257 TRACE 45516 --- [   scheduling-1] o.h.type.descriptor.sql.BasicExtractor   : extracted value ([business2_2_] : [BIGINT]) - [1]
2020-12-11 17:13:19.349 TRACE 45516 --- [   scheduling-1] o.h.type.descriptor.sql.BasicExtractor   : extracted value ([document3_2_] : [BLOB]) - [[51, 99, 51, 102, 55, 56, 54, 100, 54, 99, 50, 48, 55, 54, 54, 53, 55, 50, 55, 51, 54, 57, 54, 102, 54, 101, 51, 100, 50, 50, 51, 49, 50, 101, 51, 48, 50, 50, 50, 48, 54, 53, 54, 101, 54, 51, 54, 102, 54, 52, 54, 57, 54, 101, 54, 55, 51, 100, 50, 50, 53, 53, 53, 52, 52, 54, 50, 100, 51, 56, 50, 50, 51, 102, 51, 101, 51, 99, 52, 53, 54, 101, 55, 54, 54, 53, 54, 99, 54, 102, 55, 48, 54, 53, 50, 48, 55, 56, 54

112

Привет. JPA при pagable добавляет не правильные названия филдов в ордер бай (как написано в коде):
запрос который сгинерел хибер: ...  order by u.lastName asc, u.firstName asc, u.middleName asc limit ?
запрос:
   @Query(value = "select distinct * from users as u where match (u.first_name, u.last_name, u.middle_name) against (:term) ", nativeQuery = true)
   Page<Users> find(@Param("term") String term, Pageable pageable);
лог:
Caused by: java.sql.SQLSyntaxErrorException: (conn=3) Unknown column 'u.lastName' in 'order clause'
       at org.mariadb.jdbc.internal.util.exceptions.ExceptionFactory.createException(ExceptionFactory.java:62)
       at org.mariadb.jdbc.internal.util.exceptions.ExceptionFactory.create(ExceptionFactory.java:153)
       at org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:273)
       at org.mariadb.jdbc.ClientSidePreparedStatement.executeInternal(ClientSidePreparedStatement.java:229)
       at org.mariadb.jdbc.ClientSidePreparedStatement.execute(ClientSidePreparedStatement.java:149)
       at org.mariadb.jdbc.ClientSidePreparedStatement.executeQuery(ClientSidePreparedStatement.java:163)
       at com.zaxxer.hikari.pool.ProxyPreparedStatement.executeQuery(ProxyPreparedStatement.java:52)
       at com.zaxxer.hikari.pool.HikariProxyPreparedStatement.executeQuery(HikariProxyPreparedStatement.java)
       at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:57)
       ... 160 common frames omitted

Куда смотреть?)

spring.jpa.hibernate.naming.implicit-strategy и spring.jpa.hibernate.naming.physical-strategy

что-то странное у вас. спринг-дата вообще не должна трогать native query. сортировка просто не должна работать в нативных запросах через Pageable.

в jpa нет fullserach механизма match()  against() ...

я знаю

я говорю, что если вам нужен нативный запрос И сортировка, то вы должны доабвить ее в запрос, голым SQL

по этому и натив каеря