A
Ну да, если это не макдональдс, то вполне себе нормально
Ну тогда в таком магазине, если скажут продиктовать номер заказа, пользователи языки сломают)
Size: a a a
2019 December 04
VK
Ну тогда в таком магазине, если скажут продиктовать номер заказа, пользователи языки сломают)
Та нет, просто пусть по букве продиктуют, вообще без проблем
IM
Как у договоров.
Договор ГЭ/1246-3
и подобные штуки можно генерить из пришедших + существующих данных, без рандома
Договор ГЭ/1246-3
и подобные штуки можно генерить из пришедших + существующих данных, без рандома
A
Ну как вариант неплохой, но нужен весь этот гемор, если можно начать последовательность для id например с 10000
IM
Он чаще всего вообще не нужен, но люди чего-то боятся
A
в чем именно боль? можно пример?
Для меня было болью принимать эти портянки. В целом то теми же реквайрами выдергивается. Потом нашёл какой то гем, с которым более менее "конвертить" к хешу для update можно, но ща не посмотрю название. Дальше все это выкинулось по причинам совместимости со старым проектом. Пострадал, но было интересно, геморно и больше глядел в сторону графов. Но их я готовить не умею.
А вот с самим гемом гемор у меня был с sti и инклудами оных. В каждом сериализаторе приходилось прибивать гвоздями тип и при вытаскивании большой портянки с кучей инклудов были уже не помню какие проблемы.
А вот с самим гемом гемор у меня был с sti и инклудами оных. В каждом сериализаторе приходилось прибивать гвоздями тип и при вытаскивании большой портянки с кучей инклудов были уже не помню какие проблемы.
A
Ну а как тогда можно узнать uuid до сохранения в бд?
Дык его и так нет до сохранения
A
Постгрес, да.
В постгре есть модуль, там все поцарски 😃 а вот в других СУБД все плохо :(
MK
У меня есть небольшой сервис для риэлторов, есть клиенты у которых он установлен на отдельные сервера, между ними идёт обмен квартирами, домами и тд, uuid очень хорошо для такого подходит, один объект во всех базах с одним ID
ES
Mihail Kolebaev
У меня есть небольшой сервис для риэлторов, есть клиенты у которых он установлен на отдельные сервера, между ними идёт обмен квартирами, домами и тд, uuid очень хорошо для такого подходит, один объект во всех базах с одним ID
У меня event-based архитектура
ES
вроде бы неплохо ложится.
MK
вроде бы неплохо ложится.
А можно поподробнее?
AD
Это как?
Сложно сегодня объяснить, завтра напомни пожалуйста
AD
Ок, а как тогда быть, допустим для модели order primary key - uuid, но пользователю все равно нужно знать номер заказа. Да можно создать serial field, но тогда тереятся смысл безопасности того, что пользователи видят, сколько уже заказов в системе.
Ты можешь сделать сиквенс поле в постгресе, в чем беда?
AD
Ваш заказ - a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11
В таких случаях обычно либо делают сокращялку заказа, либо отдельное поле которое автоматически и атомарно обновляется. Но тут тоже подвох, что делать, если ты хочешь обнулять счётчик каждый день?
AD
вроде бы неплохо ложится.
Там вообще грех не использовать ююид
f🤔
Йеп, логика генерации номера заказа вообще никак не связана с чисто техническими аспектами, pkey используют просто потому что это самое простое решение
A
В таких случаях обычно либо делают сокращялку заказа, либо отдельное поле которое автоматически и атомарно обновляется. Но тут тоже подвох, что делать, если ты хочешь обнулять счётчик каждый день?
Какие проблемы тут могут возникнуть с обновлением? Просто uuid скрывает кол-во заказов, а это доп. поле будет их палить
AD
Йеп, логика генерации номера заказа вообще никак не связана с чисто техническими аспектами, pkey используют просто потому что это самое простое решение
Все так
f🤔
Какие проблемы тут могут возникнуть с обновлением? Просто uuid скрывает кол-во заказов, а это доп. поле будет их палить
У тебя заказы могут именоваться вообще как угодно же