REDkiy

Мега-Учебник Flask, Часть XVII: Развертывание под Linux

И до 19 главы включительно.

Устал читать на эту тему. Пришёл для себя к такому выводу:
Модель:
- Описываю таблицу в нотации SQLAlchemy в виде класса.
- Делаю статический метод с помощью декоратора @staticmethod, в нём делаю некую логику для получения данных из этой таблицы, передаю некие параметры и соответственно им выдаю результат.
- С помощью декоратора @property и последующего декоратора @bla-bla.setter делаю метод который модифицирует состояние значений класса с учётом уже существующих данных в БД, а также имеет возможность изменения пересекающихся данных уже имеющихся в БД, и сохраняет новую запись.

Контроллер:
- Получает данные из БД с использованием статического метода модели, подставляет их в Представление (название Вид мне разонравилось) и отправляет его пользователю.
- После ввода или изменения данных пользователем в Представлении, получает их и создаёт или изменяет с помощью метода @bla-bla.setter модели.

Представление:
- Отображает и позволяет ввод данных пользователем.
- Проводит валидацию данных перед отправкой контроллеру. Например проверяет правильность ввода e-mail. И возможность установки какого-то значения в определённых диапазонах с учётом уже существующих в БД.

Вопрос вот в чём, так нормально? Или стоит сделать проверку с помощью @staticmethod возможности установки значения в самой модели и в представлении просто получать True с его помощью если проходит и соответственно выдавать сообщение пользователю.

Я бы вместо:
event.delete()
сделал:
db.session.delete(event)

Правда не совсем понимаю в чём разница. :-)

Иногда бывает нужно почистить проект от скомпилированных файлов *.pyc. Не знаю уж почему.
Судя по предыдущему ответу это должно помочь.

У Гринберга в книге "Разработка веб-приложений с использованием Flask на языке Python" есть пошаговое описание деплоя на Heroku.

www.linuxspace.org/archives/10326

По этой ссылке есть статья, которая возможно подскажет решение.

В целом разобрался. Не знаю насколько я прав. Моё видение таково.
Отношения это больше объектный подход. При использовании отношения в таблицу добавляется "как-бы поле" в котором находится итерируемый объект (как-бы список) значений из второй таблицы соответствующих первичному ключу из первой таблицы.
join больше похож на SQL-оператор, он склеивает две таблицы по первичному ключу первой таблицы и его значению из второй. И работаем с получившейся таблицей. В таком случае можно обойтись полностью без отношений.