Если мне память не изменяет, когда у тебauto increment например как в mysql и простом варианте ostgres, о узнать следующий айдишник почти не реально. Тот жу max дает тебе приблительное значение. А вот с последовтельностью там иначе. Ты можешь вызвать next_val и значение для тебя зарезервируется
Вроде как при персисте уже есть id в сущости, но это не точно (в случае в постгре)
Павел
Михаил
Если мне память не изменяет, когда у тебauto increment например как в mysql и простом варианте ostgres, о узнать следующий айдишник почти не реально. Тот жу max дает тебе приблительное значение. А вот с последовтельностью там иначе. Ты можешь вызвать next_val и значение для тебя зарезервируется
Не запезервируется а просто увеличится и запрос вернёт увеличенное значение
Nikolay
Если мне память не изменяет, когда у тебauto increment например как в mysql и простом варианте ostgres, о узнать следующий айдишник почти не реально. Тот жу max дает тебе приблительное значение. А вот с последовтельностью там иначе. Ты можешь вызвать next_val и значение для тебя зарезервируется
Так там сейчас и в том, и в другом случае сиквенс, только по-разному работает
Михаил
То есть если ты им не воспользуешься оно не вернётся в пулл
Илья
А чо делаешь?
да особо то ничего. стандартные методы сессии использую has, get, set периодически в логах ловлю такую ошибку
Nikolay
Так там сейчас и в том, и в другом случае сиквенс, только по-разному работает
постгре очен блюдет обратную совместимость и не удивлюсь если в старой версии они его добавили как обертку
Nikolay
Соглы, слово резервируется не очень верное
Nikolay
Просто в теории, если у вас последовательность, получить id для своей сущности не проблема. А если автоинкремент - проблема
Илья
А чо делаешь?
конфиг тоже стандартный
session:
handler_id: null
cookie_secure: auto
cookie_samesite: lax
storage_factory_id: session.storage.factory.native
Михаил
конфиг тоже стандартный
session:
handler_id: null
cookie_secure: auto
cookie_samesite: lax
storage_factory_id: session.storage.factory.native
Илья
да, просматривал. вопрос как вылечить это =))?
Михаил
Михаил
Insert into users values (…) returning id
Михаил
Выполнится инсерт и вернётся id
Nikolay
после вставки
Nikolay
а если до? uuid и секвои это решают
Михаил
да, просматривал. вопрос как вылечить это =))?
Похоже на баг, кто-то уже присвоил сессию.
Так же может быть проблема с хранилищем сессии - может файл занят или редис не доступен
Nikolay
в автоинкременте еоторый?:)
Михаил
Или второй публичный индекс
Илья
Похоже на баг, кто-то уже присвоил сессию.
Так же может быть проблема с хранилищем сессии - может файл занят или редис не доступен
да, спасибо. покопаю в этом направлении
Михаил
А инкремент - как внутренний и приватный
Nikolay
ты что мне доказать то хочешь?:)
Nikolay
К вопросу очему доктрина может заранее заполнить id. В случаях uuid и sequence - это реально. В автоинкременте (где по старому), не реально
Михаил
Просто в теории, если у вас последовательность, получить id для своей сущности не проблема. А если автоинкремент - проблема
Ничего не хочу, отвечаю вот на этот вопрос.
Получить id после вставке поможет returning
Nikolay
после вставки да
Nikolay
то есть во время подготовки, он заполняет id и не надо делать flush
Михаил
Так я не на его сообщение отвечал а на твоё. Что не проблема - это после вставки без n+1 узнать id.
До вставки - да, проблема
Nikolay
а я все правильно там написал:) Узнать "следующий айдишник", чтобы заранее заполнить объект
Nikolay
Проблема в том, что хотелось привести к одному виду стратегию генерации ( Identity), но в некоторых случаях нужно получить id после persist (для второго варианта это не работает)
Nikolay
через none и свой костыль
Nikolay
Я не совсем понимаю, почему если везде последовательность под капотом, нельзя получить id-шник
Nikolay
Вообще не скажу:) Скорее всего последовательность под капотом разная у старого постгреса
Михаил
Я не совсем понимаю, почему если везде последовательность под капотом, нельзя получить id-шник
Вообще разницы никакой, там в обоих случаях (если смотреть на реализацию доктрины) n+1, просто идентити запрашивает после или до.
Так же при откатах транзакции в обоих случаях будут дырки
Nikolay
Вообще разницы никакой, там в обоих случаях (если смотреть на реализацию доктрины) n+1, просто идентити запрашивает после или до.
Так же при откатах транзакции в обоих случаях будут дырки
Разница, что в первом случае делается SELECT NEXTVAL('test_id_seq') для получения id после persist, а во втором нет, и возвращается null
Михаил
Разница, что в первом случае делается SELECT NEXTVAL('test_id_seq') для получения id после persist, а во втором нет, и возвращается null
Ну от персиста толка мало, нужет ещё и flush.
Nikolay
Ну от персиста толка мало, нужет ещё и flush.
Это я понимаю, но в первом варианте заранее можно получить
Nikolay
Ну от персиста толка мало, нужет ещё и flush.
такое поведение, позволяет использовать объект, до его сохранения в базу, там нотификацию отправить или ответ пользователю сразу вернуть
Михаил
А что ты хочешь? Отправить id во внешнюю систему?
А что если транзакция оборвётся или ошибка?
Nikolay
и по ооп, если ты уходить в дебри, попадалсь информация, что если ты id заполняешь после вставки, то у тебя не ооп, у тебя неполноценный объект.
Nikolay
я просто как пример привел, бизнес задачи разные бывают
Nikolay
просто у тебя объект становится независимым во время создания. Который держит состояние
Nikolay
и он уже валиден. А при вызове других методов получается он переходит из одного валидного состояния в другое
Михаил
А ооп разве про id? Если говорить про доменные сущности - это разве про id? Доменные сущности это про методы и связи. Id, секвенции это подробности о способе хранения.
Nikolay
Да про id в том числе
Nikolay
как раз на это указывает слово "связи"
Михаил
Нет, связи это просто то, как один объект хранит в себе другой.
Id это уже про релиационные бд.
Nikolay
так, это уже демагогия с вашей стороны.
Михаил
А вы путаете орм и ооп.
На этом и порешаем, да?
Nikolay
все все
Павел
и по ооп, если ты уходить в дебри, попадалсь информация, что если ты id заполняешь после вставки, то у тебя не ооп, у тебя неполноценный объект.
В ооп нет понятия валидного объекта. Это уже скорее всякие приемы типа ддд в которых entity и value object
Михаил
Фух, а то мы были в шаге от того что бы уйти в русло доказательного программирования
Павел
Фух, а то мы были в шаге от того что бы уйти в русло доказательного программирования
Спас нервные клетки)
Nikolay
Ага, а то началось уже, что id это про реляционные бд:)
Вадим
привет!
подскажите как в Api Platform обновить ресурс с под-сущностями?
Нужно чтобы оно не удалило и создало заново, а именно обновило под-сущность
Павел
привет!
подскажите как в Api Platform обновить ресурс с под-сущностями?
Нужно чтобы оно не удалило и создало заново, а именно обновило под-сущность
Ну вроде если указывать id или uri подсущности, то именно обновление идет
Павел
А если без id то оно удалит то, чего не было в коллекции/связи, а потом создаст новую коллекцию
Вадим
Вадим
щас попробую @id
Вадим
ну и айдишнек такой
"@id": "/.well-known/genid/5e1efcba05fa1a71bb8f",
он каждый раз разный
The Ant
Юра
Может овнинг и инверс не правильно прописан
Юра
У мени ту мени нужно по-моему явно прописать
Михаил
The Ant
Не хочу углубляться, но это зависит от того (ВРОДЕ КАК) что или ты меняешь коллекцию или создаёшь новую коллекцию с новыми данными и присваиваешь в поле.
Вот оно будет везде по разному работать
я хочу просто удалить сущность, и все релейшены, каскадно.
в одном проекте работает, в другом нет. втф?!
Kirill
а почему не через бд это сделать?
Kirill
https://www.techonthenet.com/sql_server/foreign_keys/foreign_delete.php
The Ant
а почему не через бд это сделать?
не люблю фк )
гемор с ними голимый. Да и неявное поведение получается, в коде не видно, что автоматом удаляется.
Kirill
задача БД - хранить данные в консистентном состоянии
Kirill
если у тебя останутся куски связей - это ОК? если да, то на уровне кода решается
Kirill
если нет, то на уровне БД
The Ant
Задача бд просто хранить данные. Консистентность опциональна :)
лишний мусор не мешает, но и оставлять его на пофиг не хочется.