AS
Ivan
Да меня тоже это немного смущает, но во всех примерах поголовно в репозиториях есть метод get_by_id. ну и поиск по нему быстрее
ну да, все так делают :) обычно сохраняют в базу а потом уже возвращают объект с заполненным id
Size: a a a
2021 February 04
AS
тк репозиторий конструирует объекты то ничего страшного что инварианты будут нарушены некоторое время пока объект не виден клиентам
AZ
Кстати, в реализации ObjectId есть инкремент на уровне процесса. Т.е. один процесс физически не может сгенерировать два одинаковых айдишника.
Вот и добавте к вероятности коллиции то, что вам надо наплодить прямо-таки туеву хучу процессов.
Вот и добавте к вероятности коллиции то, что вам надо наплодить прямо-таки туеву хучу процессов.
AZ
А, хотя счётчик можно переполнить... Но всё равно метеорит распидарасит Москву раньше.
AS
Кстати, в реализации ObjectId есть инкремент на уровне процесса. Т.е. один процесс физически не может сгенерировать два одинаковых айдишника.
Вот и добавте к вероятности коллиции то, что вам надо наплодить прямо-таки туеву хучу процессов.
Вот и добавте к вероятности коллиции то, что вам надо наплодить прямо-таки туеву хучу процессов.
ну логичнее было бы pid замешать тогда, потому что получить коллизию таймштампа проще в параллельных процессах
I
тк репозиторий конструирует объекты то ничего страшного что инварианты будут нарушены некоторое время пока объект не виден клиентам
вообще репозиторий не должен собирать объект он сохраняет уже готовый, примеры пестрят методами по типу
add(model: User)AZ
ну логичнее было бы pid замешать тогда, потому что получить коллизию таймштампа проще в параллельных процессах
Ну такое. С учётом того, что мы все внутри докеров, пиды не очень различаются.
p
Хм... Интересно оценить вероятности коллизий, если айдишником брать питонячий
id(...). Понятно, что зависит от объёма памяти...Вероятно, высокая
AZ
Вероятно, высокая
"Высокая" это очень не точно. 🙂
p
зависит от типа uuid, полностью случайные - да, хотя вероятность _крайне мала_, а которые мак + таймштамп используют не могут пересечься
а что подразумевается под "мак"? Message Authentication Code?
ПМ
думаю что Media Access Control
AS
Ivan
вообще репозиторий не должен собирать объект он сохраняет уже готовый, примеры пестрят методами по типу
add(model: User)ну да, слоистая архитектура мне со временем все меньше и меньше нравится из-за вот этого вот всего, тут можно сделать чтобы add возвращал id как раз
AS
ну тут вопрос нафиг нужен репозиторий если он умеет примерно то же что DAL
I
p
"Высокая" это очень не точно. 🙂
Ну питонячий id - это ж указатель на объект.
AZ
Ну да.
AZ
Очень надеюсь на понимание, что это шутка и я никому не рекомендую так делать. Ну так на всякий случай...
ПМ
Очень надеюсь на понимание, что это шутка и я никому не рекомендую так делать. Ну так на всякий случай...
*пошёл ревертить ветку из прода
p
Очень надеюсь на понимание, что это шутка и я никому не рекомендую так делать. Ну так на всякий случай...
Я к тому, что легко сделать так, чтобы какая-нибудь строка всегда имела один и тот же id ))
AS
Ivan
ну вот да, мне поэтому больше нравится подход когда нет никакого дала, а объект сам за собой следит, get_by_id тогда приобретает смысл что id управляется клиентом и не связан с id в базе данных (и не является PK, что отдельный бонус), а id в базе занимается уже ОРМ или код который вместо него, и он остается деталью реализации, а пользовательский id тоже можно обвешать индексами и сделать быстрым