Сергей П

Сделайте у модели вычисляемое свойство, которое будет сравнивать время с некоторой точностью. То есть таймдельта сравниваете с половиной секунды и все. При этом и в шаблонах у вас будет читабельно и лаконично, и в коде видно как вы определяете отредактирован ли пост.
Ещё вы можете сделать дополнительное целочисленное поле с номером правки. По умолчанию оно будет ноль, а при каждой правке вы его будете инкрементировать. Тогда будет видно однозначно и без вот этих вот сравнений дат.

А в чем проблема добавлять в заказ кофе отдельно, а топинг отдельно?
На самом деле не зватает данных о том. как вы собираетесь это всё запрягать.
Лучше сохранить плоскую простую структуру, а топинги просто указывать сразу после кофе.
В одном заказе может быть несколько кофе с разными топингами.
Вы можете сделать вместо ManyToMany модель произведения Заказе на Продукт в ручную:
ПродуктВЗаказе(Заказ, Продукт, порядковый_индекс).

Но вот я вижу у вас в Продукте какой-то volume. Это что значит, капучино у вас представлено в таблице продуктов всеми доступными объёмами? А топинги тоже определены объёмами?
Если так, то Продукт у вас абстрактен, а в заказе он представлен таблицей ПродуктВЗаказе.

Благодаря упорядоченности этой таблицы можно условиться, что если Продукт дополнительный, то он должен идти после продукта. в который его добавляют. Это чтобы по Заказу можно было однозначно приготовить кофе и не перепутать топинги.
Минусов такого подхода несколько:
- нужны методы перестановки элементов заказа, чтобы, например, заменить топинг к первому кофе из нескольких указанных в заказе.
- если дополнитеьный продукт вроде топинга может оказаться и основным продуктом, то флаг его дополнительности придётся указывать в модели РодуктыВЗаказе. К примеру, можно заказать лимон и текилу по отдельности, а можно лимон в качестве добавки в чай. В этом случае нельзя указать в Продукте "Лимон" атрибут "дополнительный", ну или придется заводить отдельные Продукты для одного и того же лимона.

Я бы не парился с признаком "дополнительности" у Продуктов, а вынес это флаг в таблицу ПродуктыВЗаказе и сделал бы методы перестановки элементов.
Тогда заказ бы у меня был плоский, но выглядел как-то так:

Капучино 300мл Арабика
+ Карамель
+ Корица
+ Шоколад
Эспрессо 400мл Арабика
+ Коньяк

Тогда, если девушка скажет: "ой. а можно мне ещё мятный сироп туда?"
Бариста в приложении добавит "+ Мятный сироп" и перетащит его над Эсрессо.

Плюсик будет определяться флагом в модели ПродуктыВЗаказе, а позиция целочисленным индексом в этой модели.
Индексы можно проставлять с шагом, например, в 1000, а при перестановке тогда просто апдейтить только переставляемую запись устанавливая индекс посерединке между любыми двумя соседними.

Вы немного путаете причины и следствия.
Если ML и аналитику делают чаще всего н апитоне, это не значит, что на питоне делают чаще всего аналитику и ML. Просто для аналитики и ML в питоне очень много "батареек", он в этом направлении лидер. Но основное применение питона - это бэкенд. Джанго действительно очень популярна, и его только недавно стал перегонять FastAPI соблазняя своей асинхронностью.
Прелесть и преимущество Джанги в его самодостаточности для многих направлений применения. Там и довольно элегантный ORM в коробке, и шаблонизатор, и, что часто очень важно, простя в использовании и мощная админка с системой атворизации и управления правами. Практически с голой джангой и за пол часика можно быстро набросать модель данных и развернуть MVP, причем совсем не придётся тратить время ни на авторизацию, ни на организацию всяких там систем миграций, таск-менеджмента, модульного согласования разных фичей и т.д..
А если учесть, что гитхаб ломится от готовых блогов, магазинов, чатов, виджетов, систем работы с комментариями в виде приложений для джанго, а эти приложения егко собираются в один проект и не толкаются друг с другом локтями при этом, то тут вполне можно понять почему Джанго так популярен.
Питон в целом и Джанго в частности дают скорость разработки, которой позавидуют любые другие языки и фреймворки. При этом язык довольно свежий, современный и удобный.

Однако меня смущает ваша постановка вопроса. Такое ощущение, что вы себе стек подбираете по озвученным критериям. Эдак могу посоветовать идти в перловики. На перле тонны легаси, в котором сейчас хрен кто ладу даёт, все бегут на что-то покомфортнее, а зарплаты у перловиков из-за вакуума на рынке не маленькая. Ну там, где это вижу я. Да, будущего у языка нет, но здесь и сейчас можно постричь бабла и подоминировать на своей нещаменимости=).
Java - это жирный энтерпрайз, там всегда были и будут деньги. Полагаю крупные компании не сильно боятся обучать себе джунов, потому что эти джуны не улизнут в стартапы и будут залочены на корпоративный сегмент.
Почему меня сутил ваш подход. Дело в том, что разных направлений развития много и в каждом можно преуспеть, но преуспеть в любом направлении сложнее, если вы выбрали его не по "зову сердца", а по меркантильным соображениям и требованиям рынка. У вас может просто не хватить мотивации, чтобы добиться нужного уровня профессионализма для востребованности в выбранном сегменте.

У вас, очевидно, selected_choice.votes - это строка, а вы пытаетесь применть оператор += с елым числом. Об этом вам и выдаётся ошибка. Нельзя к строке прибавить число.

Пожалуйста, впредь приводите полный код. В частности не хватает описания модели Choice.
А ещё нужно приводить целиком стек-трейс, чтобы не заставлять отвечающих читать ваш код целиком выискивая глазами причину ошибки.

В модели нужно votes сделать целочисленным,если вы хотите прибавлять к этому полю числа. Иногда тип поля меняют, но необходимые миграции не накатыают на БД и при десериализации инстанса модели у этого инстанса атрибут, обозначенный в модели как целочисленный. может оказаться строковым, как по-прежнему указано в схеме БД.

Делайте миграции или меняйте схему вручную для приведения в соответствие с моделью.

Такие ошибки возникают когда код неправильно разбит на модули и модули ссылаются друг на друга циклически. К примеру модуль А что-то импортирует из Б, Б импортирует из В, а В из А.
При импорте происходит выполнение кода импортируемого модуля, если это выполнение не было еще сделано ранее.
Нужно
1) не импортировать лишнее
2) изолировать зависимости. Выносить в отдельные мдули те части, которые не зависят от других.

Приводите конкретный пример и вам расскажут как правильно всё разбить, чтобы такой проблемы не было.

Пересоздайте БД для чистоты эксперимента, похоже раньше это поле было у вас строковым, вы в коде поменяли, а миграции правильные не сделали.
Если поможет, а данные в старой БД нужны, то либо правильно описать миграцию данных с конвертированием столбца и переименованием через промежуточный, либо просто ручками в БД один раз сделать и конвертнуть, если у вас в проде это всё ещё не запущено.