uuid4 может повторяться (оооочень маловероятно правда), а вот uuid1 не должен

но чем больше нод - тем выше риск, что повторяться оно будет (uuid4)

А как же перфоманс? При джоинах например

c uuid медленнее, конечно)

но если всё в кешах, то особо разницы и нет

А почему не держать колонку с юидом просто рядом, в отдельной колонке

Ну все в кеш не запихнешь)

мне нравится и другая особенность uuid - можно скрывать количество объектов в таблице и темпы роста этого количества

то есть если светить обычные id'шники - будет понятно, сколько у вас в системе, к примеру, юзеров или проектов или чего-нибудь там ещё

и можно измерить, сколько добавилось за месяц

то есть если светить обычные id'шники - будет понятно, сколько у вас в системе, к примеру, юзеров или проектов или чего-нибудь там ещё

А можно использовать норм ид для внутренних нужд, а наружу показывать ууид или любой другой рандом

А можно использовать норм ид для внутренних нужд, а наружу показывать ууид или любой другой рандом

Просто добавляем генератор некий и колонку в таблицу?

если нам потребуется потом разделить таблицы, то с числовыми идентификаторами будет сложнее

uuid1 же повторяться не будут ( https://hg.python.org/cpython/file/3.6/Lib/uuid.py#l529 )

а кешировать всё равно придётся, с любыми идшниками

допустим, у нас есть некие операции, которые выполняются каждый день и по итогам этого куда-нибудь пишется лог, а в базу нужно записать состояние операции и ссылку на этот лог

допустим, у нас 100 тысяч клиентов и по каждому 1 раз в день добавляется запись в таблицу

ограничения на таблицу 32Тб, как бы много, но рано или поздно это израсходуется

значит, мы будем писать, допустим, каждый год в свою таблицу

и будет меньше ошибок, если идшники повторяться не будут)

и будет меньше ошибок, если идшники повторяться не будут)

для этого имеется партицирование

гайс, через {% url %} можно 2 аргумента передать?

Да хоть десять

Хоть аллаха передавай

Лишь бы сматчилось с какой-то урлой

для этого имеется партицирование

оно вроде только недавно научилось работатьс разными серверами

ничего не имею против партиционирования в PostgreSQL 9.5 и выше, впрочем

но вот с UUID это всё можно реализовать вполне стандартным способом, это удобно

uuid1 ещё чем интересен - из него можно восстановить дату создания и понять, к какой таблице или серверу делать запрос

как-нибудь так http://stackoverflow.com/questions/3795554/extract-the-time-from-a-uuid-v1-in-python

ничего не имею против партиционирования в PostgreSQL 9.5 и выше, впрочем

У постгреса намного раньше имеется эта поддержка

я особо не вчитывался, но видел что-то такое https://www.depesz.com/2015/04/02/waiting-for-9-5-allow-foreign-tables-to-participate-in-inheritance/

вот это решение с UUID1 мне нравится

у нас 1 ключ, который уникальный и по которому без дополнительных запросов куда-либо можно узнать, куда делать запрос для получения данных по этому ключу

HALP

Точнее я так и не могу понять на что оно ругается

Точнее я так и не могу понять на что оно ругается

эээ, какое-то ограничение в бд не отрабатывает?

конфиг в базе посмотри к comments.comment_article_id

Ты видимо пытаешься сохранить в бд объект Comments и не указываешь у него comment_article

Воспользуйся дебагером

У тебя ошибка

Comments_article

В контроллере

Comment_article в моделе

Буква s

оууу

спасибо

?

class Meta обычно пишут в конце после определения элементов модели

да я знаю

но помойму так четабельней)

ещё ради +1 нет смысла дёргать всё из СУБД

ну я только осваиваю... не знаю как без этого...

Укажи related_name в поле comment_article

ну я только осваиваю... не знаю как без этого...

ну, как-нибудь так Article.objects.select_for_update().filter(pk=article_id).update(article_likes=F('article_likes') + 1)

но помойму так четабельней)

лучше в одном стиле всё делать)

открывая твой код, у другого программиста не должно складываться ощущения, что этот код писал не он

Оке)

Хай, гайс

def logout(request): logout(request) return redirect('/') url(r'^logout$', views.logout, name="logout"),

url(r'^$', views.index, name='test'),

RuntimeError at /logout maximum recursion depth exceeded

Из-за чего это?

где-то рекурсия

вот тут:

def logout(request): logout(request)

создаешь функцию, которая вызывает себя же

в официальной доке это обойдено вот так:

def logout_view(request): logout(request)

Черт, не заметил, спасибо)

ещё можно явно делать from django.contrib import auth а в коде auth.logout(request), но, наверное, не стоит

ещё можно явно делать from django.contrib import auth а в коде auth.logout(request), но, наверное, не стоит

почему не стоит?

всё равно две функции с одинаковым названием в коде - нехорошо, в любой момент можно запутаться и написать logout() вместо auth.logout()

ну, как-нибудь так Article.objects.select_for_update().filter(pk=article_id).update(article_likes=F('article_likes') + 1)

а зачем тут select_for_update?

это блокировка

но, кстати, лайки, наверное, лучше вообще в redis'е хранить

а не в PostgreSQL

тот код, который был в оригинале, не предусматривает разные ситуации, когда кто-то там что-то одновременно хочет записать (лайкнуть)

Как делают у модели User поля email тек unique?

Не лезть же в саму модель User?

User переопределяют на свою кастомизированную

а разве update одного поля не атомарная оперция?

а разве update одного поля не атомарная оперция?

ну, вот в примере выше там человек получает состояние строки таблицы на какой-то момент времени, потом дописывает туда 1 и сохраняет, за это время могло что угодно измениться и те данные уже не актуальны

это я понимаю. но запрос же превратится в '...likes = likes + 1...' разве при этом может возникнуть race?

я эти рекомендации брал отсюда https://habrahabr.ru/post/252563/

о, благодарю, сейчас ознакомлюсь

Гайс, хочу переопределить немного удаление объектов из админки, это возможно?

В доке чет нашел только про добавлении действий в админку

А что будет с полями, которые содержат идентичные значения, после добавления unique=true?

Которые ранее созданы были без этого тека

на уровне миграции - ничего

т.е. на момент применения нового свойства все будет хорошо

Гайс, хочу переопределить немного удаление объектов из админки, это возможно?

exclude = ('some_field')

select_for_update() ставит блокировку на строчку FOR UPDATE https://www.postgresql.org/docs/current/static/explicit-locking.html