> Если объект имеет метод, который возвращает сам объект, мы можем писать так:
> some_obj.set_name(«abc»).inrease_age().update_items([1,2,3]).validate().save()
>
> Это тоже частный случай монады, просто он более привычен людям, привыкшим к ООП.
Ох, ну классно! У нас, оказывается, повсюду монады :)
Вот всегда так в питоне. Берешь утюг и гладишь. А оказывается, это высокотехнологичный прибор с парогенератором низкого давления и прецизионным термостатом и некоторые диссертации на эту тему защищают.
Что-то мне подсказывает, в реальном мире не существует ни одной реальной задачи, где бы подобная магия была бы уместна. Разве что, как экзотическая зарядка для ума…
Хочу переголосовать :)
Хоть я и отметил сразу несколько (Управление проектами, Дизайн и проектирование и Python), но про Python конференций нету, а про Управление проектами и Дизайн и проектирование уже есть и не одна.
Я несколько неверно выразился. Конечно, UUID может генерить и БД — в каких-то случаях это более уместно. Другое дело, что если алгоритм тот же (или столь же годный), то этот UUID можно и клиентом генерить с тем же успехом. Особенно, если хранилище само этого не умеет.
Так это и есть UUID.
Тут надо понять, что UUID — это не какой-то конкретный алгоритм. Есть разные реализации и рекомендация RFC-4122. Более того, в общем смысле, UUID — это не обязательно 16 байт, можно и больше сделать, если необходимо.
Суть в том, что это идентификатор, который генерируется на клиенте и он гарантированно уникален.
Вы как-то жестко бредите заблуждаетесь…
С чего вы взяли, что генерация UUID это «очень дорогая» операцией? Вы точно не путаете UUID с хэш-функцией?
Я вам, без всякого сарказма, советую мысленно проделать следующее упражнение. Представьте программу на ассемблере, которая формирует UUID. Не в точности до команды, а просто «крупными мазками», чтобы оценить масштаб.
А после этого представьте всю махину TCP-стека — тоже на ассемблере.
И сравните, просто по количеству машинных команд, что «дороже» — сходить куда-то за значением по сети или просто его сгенерить.
Кажется, ребята из Twitter рассуждали также и поэтому сделали свой сервер, который генерирует ключи (см. ссылку в тексте).
Это, по сути, и есть тот самый «арбитр», про который вы говорите, только ходить к нему надо «до», а не «после» (откат закоммиченой транзакции — лучше про это не думать вообще, чтобы с ума не сойти).
Как по мне, такое решение ближе к централизованному генератору ключей — есть отдельный компонент, про который еще думать надо, А что будет, если он упадет?
Это заблуждение. UUID как раз и придуман для того, чтобы «проверка на сервере» была не нужна (она невозможна в распределенной системе).
Почитайте как устроен UUID и вы поймете, что надо как-то очень хитро стараться (например, крутить часы), чтобы получить хотя бы не нулевую вероятность сгенерировать два одинаковых UUID.
Ну, на самом деле я почти согласен везде UUID использовать. Но в том и дело, что не всегда получается или не всегда удобно.
> Требования по увеличения (вместо случайности) скорей всего не являются значимыми.
> В случае распределённых данных эти требования невозможно выполнить.
Распределение зачастую делается по хэшу, а не по самому ключу. Я имел ввиду ситуацию, когда у нас (на уровне приложения) уже есть список ключей, то иногда было бы круто при помощи простой сортировки получить их естественную последовательность.
> some_obj.set_name(«abc»).inrease_age().update_items([1,2,3]).validate().save()
>
> Это тоже частный случай монады, просто он более привычен людям, привыкшим к ООП.
Ох, ну классно! У нас, оказывается, повсюду монады :)
Вот всегда так в питоне. Берешь утюг и гладишь. А оказывается, это высокотехнологичный прибор с парогенератором низкого давления и прецизионным термостатом и некоторые диссертации на эту тему защищают.
Хоть я и отметил сразу несколько (Управление проектами, Дизайн и проектирование и Python), но про Python конференций нету, а про Управление проектами и Дизайн и проектирование уже есть и не одна.
Очень интересно про python — можно посмотреть на тестовый код?
Тут надо понять, что UUID — это не какой-то конкретный алгоритм. Есть разные реализации и рекомендация RFC-4122. Более того, в общем смысле, UUID — это не обязательно 16 байт, можно и больше сделать, если необходимо.
Суть в том, что это идентификатор, который генерируется на клиенте и он гарантированно уникален.
бредитезаблуждаетесь…С чего вы взяли, что генерация UUID это «очень дорогая» операцией? Вы точно не путаете UUID с хэш-функцией?
Я вам, без всякого сарказма, советую мысленно проделать следующее упражнение. Представьте программу на ассемблере, которая формирует UUID. Не в точности до команды, а просто «крупными мазками», чтобы оценить масштаб.
А после этого представьте всю махину TCP-стека — тоже на ассемблере.
И сравните, просто по количеству машинных команд, что «дороже» — сходить куда-то за значением по сети или просто его сгенерить.
code.flickr.com/blog/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
Это, по сути, и есть тот самый «арбитр», про который вы говорите, только ходить к нему надо «до», а не «после» (откат закоммиченой транзакции — лучше про это не думать вообще, чтобы с ума не сойти).
Почитайте как устроен UUID и вы поймете, что надо как-то очень хитро стараться (например, крутить часы), чтобы получить хотя бы не нулевую вероятность сгенерировать два одинаковых UUID.
> Требования по увеличения (вместо случайности) скорей всего не являются значимыми.
> В случае распределённых данных эти требования невозможно выполнить.
Распределение зачастую делается по хэшу, а не по самому ключу. Я имел ввиду ситуацию, когда у нас (на уровне приложения) уже есть список ключей, то иногда было бы круто при помощи простой сортировки получить их естественную последовательность.