AZ
Монговый ObjectId это кармический брат UUID.
Size: a a a
2021 February 04
AZ
Собственно, и в любой базе никто не мешает использовать нормальные айдишники, а не секвенсы. Но про это мало кто знает.
AS
Ivan
Привет, при использовании паттерна репозиторий хочу id сущности привязать к id в базе данных, проблема в том что я не знаю какой id у сущности когда та создается в логике, потому что она еще не сохранена в базе. Как быть в такой ситуации? Оставлять id не заполненным тогда надо следить когда он есть когда его нет, сделать id в форме uuid ударит по перфомансу, а где получить актуальный id я тоже не знаю(((
id в базе и id в коде это разные вещи, id в коде обеспечивается уникальностью объекта в памяти, id в базе возникает после сохранения в базу и в логике он не нужен, соответственно и помнить о нем не надо и доступ к нему иметь нельзя, иначе это будет текущая абстракция
AS
то что иногда используют id из базы как id объекта это просто ленивое проектирование
AZ
Хм... Интересно оценить вероятности коллизий, если айдишником брать питонячий
id(...). Понятно, что зависит от объёма памяти...AZ
Наркомания, да.
AS
Хм... Интересно оценить вероятности коллизий, если айдишником брать питонячий
id(...). Понятно, что зависит от объёма памяти...не надо так :)
ПМ
мне вот интересно, можно ли быть настолько невезучим, чтобы напороться на 2 одинковых uid
AZ
Очевидно, что не надо. Но вечело же.
AS
мне вот интересно, можно ли быть настолько невезучим, чтобы напороться на 2 одинковых uid
зависит от типа uuid, полностью случайные - да, хотя вероятность _крайне мала_, а которые мак + таймштамп используют не могут пересечься
AZ
мне вот интересно, можно ли быть настолько невезучим, чтобы напороться на 2 одинковых uid
Это легко оценивается. По большому счёту, в наших с тобой условиях эта вероятность стремиться к нулю, так как в этом айдишнике есть время (пусть с квантованием до секунды) и хеш хоста (или случайное число). Т.е. должно очень сильно неповезти.
I
id в базе и id в коде это разные вещи, id в коде обеспечивается уникальностью объекта в памяти, id в базе возникает после сохранения в базу и в логике он не нужен, соответственно и помнить о нем не надо и доступ к нему иметь нельзя, иначе это будет текущая абстракция
не я не про id(...) я про id модели как идентификатор сущности
AZ
зависит от типа uuid, полностью случайные - да, хотя вероятность _крайне мала_, а которые мак + таймштамп используют не могут пересечься
Могут пересечься, конечно же. Если ты в рамках секунды два айдишника сгенеришь.
AZ
Можно оценить, сколько их надо генерить, чтобы хотя бы раз в год получить коллизию. У меня нет такого хайлоада даже близко. Да и, думаю, ни у кого в этом чате нет.
ПМ
Это легко оценивается. По большому счёту, в наших с тобой условиях эта вероятность стремиться к нулю, так как в этом айдишнике есть время (пусть с квантованием до секунды) и хеш хоста (или случайное число). Т.е. должно очень сильно неповезти.
звучит логично, это надо очень много писать, чтобы встретить проблему
AS
Могут пересечься, конечно же. Если ты в рамках секунды два айдишника сгенеришь.
в рамках 100нс, но да
ПМ
вот зачем нужно писать на питоне, чтобы коллизию не словить))
AZ
в рамках 100нс, но да
Зависит от реализации. Я больше на монговский ObjectId ориентируюсь. У нас секунда.
I
id в базе и id в коде это разные вещи, id в коде обеспечивается уникальностью объекта в памяти, id в базе возникает после сохранения в базу и в логике он не нужен, соответственно и помнить о нем не надо и доступ к нему иметь нельзя, иначе это будет текущая абстракция
Да меня тоже это немного смущает, но во всех примерах поголовно в репозиториях есть метод get_by_id. ну и поиск по нему быстрее
AS
Ivan
не я не про id(...) я про id модели как идентификатор сущности
я тоже не про id(), я про общее понятие identity объекта :)