поддерживают же

очень медленно

да?

аа))

но поддерживают

но, если ты только зашел в это все - бери и юзай) потом через какое-то время прозреешь и выбросишь ))

a few moments later... "ой, я его юзаю в одном проекте, так исторически сложилось, но не советую"

ну а что советовать чуваку? идти в доку смотреть и не понимать как написать свой юзер провайдер?

стебу)

можете бросаться камнями, но если чувак новичок уровня джуна который только вот вот что-то пытается делать - пусть берет фос и норм

дак а гайдов в нете какбудто больше и нет никаких

что-то да контрибютят

ага, вижу

всё ок. С секьюрити сам не сразу въехал. Правда и фос не ковырял на тот момент

можете бросаться камнями, но если чувак новичок уровня джуна который только вот вот что-то пытается делать - пусть берет фос и норм

дальше будет фиксить/чинить/менять по мере надобности

всё ок. С секьюрити сам не сразу въехал. Правда и фос не ковырял на тот момент

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

дальше будет фиксить/чинить/менять по мере надобности

и с фреймворком разберусь хорошенечко уже)

ну вот) так что иди сделай что-то рабочее и будешь менять части как только они будут ботлнеком

на твоем этапе ща главное решить задачу, а не задрочить код

согласен

там есть гайд как lexikjwt + fosuserbundle склеить

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

аналогично. Имел в виду, что не за час разобрался

да, доки по сукурити имеют много букаф

касательно такого момента "entity should always be valid" - как проверять уникальность только что созданой сущности до persist/flush ?

у тебя констрейнты в базе для чего даны

так это в базе

мне не надо уже в конце это проверять и ловить uniqueConstraint

мне надо вот прям тут на месте

UniqueEntity/UniqueEntityValidator

UniqueEntity/UniqueEntityValidator

ну так это сработает когда я буду вызывать flush, но на текущем уровне у меня нет entityManager чтобы флэшнуть. можно конечно в репозитории создать save($entity) а там внутри уже $this->_em->persist/flush, но это кажется грязный хак, не?

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

какой профит отказываться от персиста/флаша, запихивая их в один метод ;c

пинай @fes0r , а я послушаю, мне самому интересно

но я нахожу твой кейс, чутка странноватым

имхо

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

пинай @fes0r , а я послушаю, мне самому интересно

ась?

касательно такого момента "entity should always be valid" - как проверять уникальность только что созданой сущности до persist/flush ?

я понимаю что доктрина сама откатит прямые релейшны. а если вот я ручками их создаю без доктрины? надо будет и руками все это откатывать, те же файлы например

касательно такого момента "entity should always be valid" - как проверять уникальность только что созданой сущности до persist/flush ?

уникальность сущности не относится к самой сущности. Дальше - много вопросов о том что ты и как пихаешь. У меня например есть штуки которые нельзя разрулить просто ключами в базе - потому приходится чрезе рэдис ставить писсемистик лок при добавлении в репос и тот уже кидает ошибку

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

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

ну так проверяй, главное исключить вероятность того что между "проверкой" и "вставкой" никто не успеет вставить)

ну то есть гарантируй атомарность а потом пляши

так я не знаю как

вот и спрашиваю как это сделать без вызова persist+flush

но ведь каждая проверка на уникальность = +1 запрос в базу, вряд ли можно их как-то заперсистить и заккомитить все сразу

вот и спрашиваю как это сделать без вызова persist+flush

ну вот смотри - у меня есть ситуация когда ни персист ни флаш мне ответа на вопрос не дают)

и я решаю это через рэдис который мне позволяет делать атомарные штуки

пришел запрос - сказал мне "я собираюсь машнить чето с этой фигней". Остальные штуки будут ждать пока ресурс освободится. Семафор типа или мьютекс

но ведь каждая проверка на уникальность = +1 запрос в базу, вряд ли можно их как-то заперсистить и заккомитить все сразу

транзакции

дык я о том же

интересное наблюдение - 90% ситуаций когда у меня возникал эксепшен что "не уникальная запись" - это когда юзер два раза кликал по кнопке и уходило два запроса

потому "проверка заранее" не всегда имеет смысл

ситуаций когда юзер забыл что он зарегался происходит в разы меньше

подожди это куда то в глубь уже уходите. давай проще - вот есть dto, есть сущность. я делаю например $newEntity = $someFactory::makeEntityFromDTO($dto); как мне этот $newEntity проверить что он уникален, пусть например по комбинации 2 полей? например name-description

ну я к тому, что не вижу профита проверять заранее, это почти всегда N+1 проблема, а констрейнты в базе и ее целостность, самый простой вариант

подожди это куда то в глубь уже уходите. давай проще - вот есть dto, есть сущность. я делаю например $newEntity = $someFactory::makeEntityFromDTO($dto); как мне этот $newEntity проверить что он уникален, пусть например по комбинации 2 полей? например name-description

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

не надо усложнять

в чем профит, чекать до персиста, не понимаю

хаха

дак я про это и спросил

при флаше у тебя будет конкретное исключение - конфликт бла бла бла

вот его транслируешь клиенту как "ты уже зареган, может быть ты просто пароль забыл?!"

но далеко не всегда можно повесить индекс в базе и быть счастливым)

но далеко не всегда можно повесить индекс в базе и быть счастливым)

конечно

ERROR: S client not available

хотя... не пожалуй это редкий кейс...

но когда можно не усложнять

лучше не усложнять)

но бывает, у меня например юзерам запрещено иметь одинаковый email но в некоторых ситуациях (групповые аккаунты) - можно. Правда тут больше проблема с херовой моделью данных но я пока не смог в этом убедить коллег

так в конце концов

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

зачем проверять "до" это уже другой вопрос)

ну можешь метод в модели сделать

checkIfExist

я хотел бы в репозитории сделать этот метод

это вполне логично было бы. а там внутри уже try/catch с возвратом true/false

просто пока ты говоришь "зачем проверять до, это уже другой вопрос", никто не понимает какого рода профит ты пытаешься получить переливая из пустого в порожнее

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

других надежных способов нет

просто пока ты говоришь "зачем проверять до, это уже другой вопрос", никто не понимает какого рода профит ты пытаешься получить переливая из пустого в порожнее

не обижайся но я часто вижу вопросы, не только тут, вообще, в духе "зачем". зачем - какая разница ) все любят спрашивать зачем )

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

не обижайся но я часто вижу вопросы, не только тут, вообще, в духе "зачем". зачем - какая разница ) все любят спрашивать зачем )

от задачи которую ты решаешь зависит решение которое эффективнее для этой задачи. Вот почему все спрашивают зачем.

иногда путем нескольких вопросов "зачем" можно придти к тому что задача неверно поставлена или цели неверны

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

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

не обижайся но я часто вижу вопросы, не только тут, вообще, в духе "зачем". зачем - какая разница ) все любят спрашивать зачем )

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

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

тогда только сохранение в базу

на энджинксе лимитировать число запросов в секунду ;)

@fes0r а как ты борешься с парсерами, в случае апихи?

на энджинксе лимитировать число запросов в секунду ;)

один из возможных вариантов, че

@fes0r а как ты борешься с парсерами, в случае апихи?

рэйт лимит)

я тут недавно доклад от 2гис смотрел на эту тему, вспоминал тебя, все интересно было спросить

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

рэйт лимит)

а когда нельзя рейт лимитить налево и направо

по сути нужно строить realtime аналитику, получается

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

по сути нужно строить realtime аналитику, получается

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

ну да, я так делал на энджинксе ;) когда беком у меня была не база, а апи, которая оказалась подвержена состоянию гонки... быстрый костыль