номер телефона + номер заказа у клиента лучше имхо
не нужен никакой номер заказа
yopp
yopp
это избыточная информация
Артём
"Ну что то подобное должно приходить на почту клиенту.
Вот вопрос с номерами заказов. Как они формируются? Просто такой номер не продиктовать, если что то идет не так"
Артём
Дело было в том как это сделать, а не для чего оно ему)))
yopp
а вы разберитесь для чего оно ему
s0menickname
Ну вот:) так и знал, что ошибка в другом
зато узнал, что используешь враппер и теперь легче будет формулировать вопросы
yopp
и получить на выходе один и тот-же идентификатор
s0menickname
перефразируй пожалуйста, я не понял
Артём
Аааа, пока выполняется один запрос, дернет еще раз БД?
Артём
Ты про это?
yopp
да, два запроса в один момент могут сделать find и получить одно и то-же число. при плохом дизайне можно получить deadlock
Артём
понял принял
yopp
отдельная коллекция со счётчиками из которой никогда не делается find, а номера счётчиков получаются исключтельно через атомарный инкремент с помощью findAndUpdate
Артём
отдельная коллекция со счётчиками из которой никогда не делается find, а номера счётчиков получаются исключтельно через атомарный инкремент с помощью findAndUpdate
Ну я уж понял) Спасибо, сейчас переделаю тогда)
s0menickname
да, два запроса в один момент могут сделать find и получить одно и то-же число. при плохом дизайне можно получить deadlock
сомневаюсь что у него многопоточная программа
yopp
и уникальный индекс на поле
Nick
можно использовать Date(), например
Никогда больше такое не советуйте, события имеют природу быть одновременными, т.к. Точность дат как правило мала или вообще усекается до секунд
s0menickname
Nick
И что? Больше 1к событий в секунду не влезет никак
yopp
время вообще может течь в любую сторону
yopp
время — плохой идентификатор
Nick
Это еще одна веселейшая сторона
yopp
есть отдельное монотонное время, но это не Date()
Nick
Чтобы получить коллизию
yopp
причём в прицнипе двух :) а не одновременно
Nick
Либо наворачивать контроль сверху по типу уникальных индексов и пересохдания поля ид с новой временной меткой
Nick
Короче ненадо больше так делать, лучше предлагайте гуиды в качестве ид полей
Nick
А для юзера всегда можно генерить значение в отдельном поле и не обязательно это должен быть именно id
Nick
++
А вот это вы зря, если вы сейчас не имеете многопоток, то не факт, что завтра ваш заказчик не захочет этого, а у вас уже допущения что тольно однопоток
Nick
Кстати ктонить вкурсе кишков нодовского драйвера в асигхроне он параллельно ранает запросы га монге или выстраивает какнить чтоб как и сама монга было степ бай степ?
s0menickname
причём в прицнипе двух :) а не одновременно
а как получить коллизию при в принципе двух заказах?
Nick
вероятность коллизии 0.1% при двух заказах в секунду
(дальнейшее уже оффтоп) вообще достаточно не нулевой вероятности и требования к стабильности, что нужно это все обрабатывать
Nick
Но к сожалению реальные
s0menickname
Nick
Да досточно насинкануть с нтп время
Ivan
yopp
ntpd в нормальых условиях аккуратно подстраивает время
Nick
Да, если этт не делакт адмиг ручками на локально нтп
s0menickname
(дальнейшее уже оффтоп) вообще достаточно не нулевой вероятности и требования к стабильности, что нужно это все обрабатывать
время программиста может стоить дороже чем решение маловероятной проблемы
yopp
ето да
s0menickname
но это вряд ли тот случай
yopp
время программиста может стоить дороже чем решение маловероятной проблемы
да, по этому не надо использовать date
yopp
есть ObjectId, где всё уже придумано
Nick
время программиста может стоить дороже чем решение маловероятной проблемы
Это резонный момент, все правильно стоимость рисков нужно явно считать
s0menickname
последние 4 цифры Date() удобнее
yopp
и мы приходим к тому, что просто не нужно делать номеров заказа
s0menickname
когда перевалит за 10к заказов — 5 цифр
s0menickname
гыгы
yopp
потому что это избыточная информация
s0menickname
номер телефона тоже не очень всем работникам техподдержки говорить
yopp
зачем его говорить вообще?
s0menickname
зачем его говорить вообще?
ну если вопросики связанные с конкретным заказом обкашлять надо
s0menickname
с техподдержкой
yopp
но зачем?
s0menickname
зачем вопросики обкашливать?
yopp
если номер определяется, а если человек пишет ручками, то его можно сразу авторизовать
s0menickname
если номер определяется, а если человек пишет ручками, то его можно сразу авторизовать
определять номер это надо отдельную хрень писать же
yopp
...
s0menickname
время программиста на эту хрень может быть дороже освобождения клиентов от насилия
yopp
вы просто считать не умеете
yopp
это не первый раз когда всплывает «номер заказа» и это лакмусовая бумажка классического безумного оверинжениринга
yopp
номер заказ требует от всех сторон усилий
yopp
при каждом обращении
yopp
это время и клиента, и сотрудиников технической поддержки
yopp
вместо того чтоб решать проблемы, номер заказа создаёт ещё больше проблем. номер заказа — это внутреняя кухня того, у кого делают заказы. хороший номер заказа это многобукв, которые решают проблемы в жизненом цикле выполнения этого заказа. Клиенту все эти номера заказов никогда не нужны. Они для него не представляют никакой ценности, потому что номер заказа у 99% клиентов — «последний»
yopp
И вместо того чтоб морочить всем по кругу голову номерами заказов, можно потратить ресурсы на решение настоящих проблем, типа быстрой аутентификации клиента при его обращении.
Огромное количество екоммерца, не может блин свою сессию в хелпдеск нормально перекинуть.
Nick
вместо того чтоб решать проблемы, номер заказа создаёт ещё больше проблем. номер заказа — это внутреняя кухня того, у кого делают заказы. хороший номер заказа это многобукв, которые решают проблемы в жизненом цикле выполнения этого заказа. Клиенту все эти номера заказов никогда не нужны. Они для него не представляют никакой ценности, потому что номер заказа у 99% клиентов — «последний»
т.е. предполагается идентифицировать какимнить образом клиента и этого будет достаочно опредлить заказ?
Nick
пока дописал уже считай ответил)