э... зачем делать select после каждого inserta

а если сиквенс или дата обновления, то что ставит база, или тригером ченить еще ставится, юзер из контектса конекшена например

ну флаг бы сделали какой нить типа этого транзакш false. Когда ты уверен что данные новые, если совпадение PK будет всё равно есть же onConstrait

я сейчас призму как орм использую, тут ваще тонны лишних запросов и как то для себя решил - пофигу, главное просто кодить бэк и фронт, а то что тормозить будет - то на sql перепишу)

Ну это да. Не понимаю просто почему не хотят это как то решать

тайп орм вроде зафризился, его не улудшают

Ну мастер ветка 12 дней назад updated  )

может как то с этим связанно, тут вот чет пишут https://github.com/typeorm/typeorm/issues/3251

(breaking) remove update and insert methods from repository because they confuse users

Ну как то не убрали это до сих пор )

Лично мне нужно обновить, я предварительно забрал сущность со всеми полями, поменял поле и отправил на обновление метолом save. Но тайпорм всё равно делает ещё один запрос на получение данных.

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

не проверял с массивом сущностей, в данный момент заметил именно на обновлении одной сущности.

это решается через insert + onConflict

в квери билдере

и не будет у тебя 2х запросов

Он кофликт основан на ключах, это другое

Is it safe to use getRepository() inside an entity beforeUpdate hook if the caller is executing within a transaction?

Русскоязычная конфа

I see that Entity Listeners simply do not support transactions, as there is no way to pass down the transactionManager instance to them.

I think it’s wrong to do queries/transactions inside event listener. First there’s a chance to trigger other listeners and eventually cause endless loops. Second is if you have a group of operations that needs to be executed as a single transaction, they should coexist in calling code. Maybe place that code in your entity repository. It’s okay if one repository uses another…

Listeners are primarily intended for validations and pre-/post-processing data. Maybe queuing some side effects when entity changes, like refreshing a cache…

> I think it’s wrong to do queries/transactions inside event listener. First there’s a chance to trigger other listeners and eventually cause endless loops.

Even if it's a simple validation? That queries the database, that is