то и токен соответственно не нужен

Все, я потыкал, допер вроде бы, спасибо👍👍

На сторону клиента uuid отдавать лучше, чем id, так как по id понятно количество объектов в базе и недельный прирост при желании тоже можно посчитать

Например, по id пользователя понятно количество клиентов и прирост, это выглядит как утечка закрытой маркетинговой информации, не секретной, но зачастую закрытой

зато будет гимор с бд. как и писал зависит от задачи.

мои рекомендации по данному вопросу такие:

в каждую модель добавлять

id = models.BigAutoField(_('ID'), primary_key=True)

и

uuid = models.UUIDField(verbose_name=_('UUID'), unique=True, null=False, blank=True, default=functools.partial(uuid1_for_model, "ModelName"))

[ну, у меня кастомный генератор uuid, в default'е можно и упростить]

далее, если есть некий код в рамках приложения - использовать id, иначе uuid, в ответ на все запросы наружу выдаётся только uuid

ну, и отношения между сущностями - их нет, если это разные приложения, используется models.UUIDField (то есть другие приложения и тот код, который на фронтенде, этих id не знают)

то есть какой-нибудь OneToOneField возможен только для связи моделей из 1 приложения

в других случаях это будет UUIDField

такой подход позволит в будущем проще слезть с Django на тот же FastAPI или что-нибудь другое и/или разделить 1 большой проект на несколько более мелких (микросервисы)

есть вариант использовать UUIDField с primary_key=True, но мне такой вариант не нравится по соображениям оптимизации скорости выполнения запросов СУБД

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

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

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

а так исходя из текста выше, что-то мне подсказывает что категории не будут особо анализировать конкуренты и поднайти id=27 vs нцать буков  попроще, да и какой анализ ну ок 100 категорий товаров и что?
я уж не говорю о том, что если в урл это пойдет, то сейчас поисковики топят за укороченные ссылки и даже не слуги пихают, а как раз id интовые.

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

поэтому пихать uuid во все подряд или чтобы тупо шифровать никому не нужные данные - так себе занятие и выстрел в ногу
и уж тем более primary key,
прсото потом с этим добром еще конверторы делать в django admin, потом тот же serach_fields по uuidу отваливается в админке, тк хранится он без палок в бд, а и ищется с палками, ссылки в админке подкручивать и тп тк паровозик из 36 символов сжирает место

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

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

попробу определенный app мигрейтить
migrate app

если не зайдет - то смотрим migrations папку и что в базе лежит - или там меняем названия или там

я пробовал апп мигрануть

он мне и сказал что все мол збс

миграции актуальны

смори базу

но по факту нифига подобного

получается что в базе уже записи лежать о миграции