Форум на Python/Flask

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

а как не программисты оправдывают форумы ? или преподу все равно ? Меня вот в магестратуре заставляли такие штуки притягивать за уши к специальности

Посмотри на батарейки типа flask-security, flask-sqlalchemy, flask-migrate.

Вот еще не плохой примерчик. https://github.com/mattupstate/overholt

Ну что, поздравляю, теперь ты типа программист :) Я тебе помогу немного вечером, докину docker образ и может немного подкорректирую код.

Flask sql-alchemy супер.

Пароли plain-text'ом что-ли в базе хранишь? Не надо так.

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

flask-sqlalchemy

Нахер-нахер, если уж хочется ORM, то лучше посмотреть на pewee или pony, второй лично мне больше зашел.

flask-migrate

Миграции вообще хорошая штука, рекомендую. Я пользуюсь yoyo, он не завязан на другие фреймворки.

flask-sqlalchemy

опять же на вкус и цвет.

flask-migrate

автоматически генерирует миграции, очень удобно.

__pycache__ точно надо было коммитить?

Забыл, что есть гит игнор, сейчас изменю

Прошу обратить внимание, что я учусь не на программиста!

Вот так всегда. Сапоги тачает пирожник, пироги печет сапожник... Россея...

И файлы копии удали по типу

https://github.com/Lenin1917/FlaskForum/blob/master/templates/index.html~

выкинь из view логику работы с БД. SQLAlchemy тебе в помощь

У нас вся параллель, хоть у нас и физико-математические специальности, изучает программирование. Пишем контрольные от расчёта движения планет на C++ до бухгалтерского учета макросами в Excel.

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

«Дяденька, я не настоящий сварщик» (с) ЛОЛ.

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

Да ок, но форум тут при чем ? Или ты сказал что это специальный форумный движек для математиков-физиков ?

Вообще, у меня специльность не лабораторная/заводская, а больше офисная. Препод попался хороший, а не дед какой-то и разрешил использовать любой ЯП на выбор. Потом просто дали темы в количетсве около 9 штук и сказал пилите на чем хотите, но помогать я вам буду только если будете писать на js/php/python. Выбрал именно форум, так как я ими чаще всего пользкюсь по жизни

ORM в каждой щели, вне зависимости от того нужна она или нет?

Насколько я помню у SQLite проблемы со сравнением строк в юникоде. Может стоит выбрать другой вариант например MySql?

Насколько сложно переходить с SQLite на MySQL?

если бы ты использовал ORM или по крайней мере выносил логику работы с БД в отдельный модуль - то несложно.

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

Песец. Обычно в ВУЗе предлагают какую нить задачку мат.-физ. посчитать.

Ты можешь смело удалять все комментарии из кода, так как они комментируют очевидные вещи и только мешают.

Используй комментарии только в том случае, когда есть что-то неочевидное.

Если последовательность операторов под if заканчивается return, то else не нужно - в нем нет смысла.

Избавься от лишних отступов, переопределив условия.

Твой код

@app.route('/') 
def root():

    if 'user' in session: # Если пользователь в сессии
        db = sqlite3.connect(DB) # Подцепляемся к базе данных
        cur = db.cursor() # Имитируем консоль?

        
        # Исполянем команду как в базе данных

        thread = cur.execute('SELECT * FROM thread group by id order by date desc').fetchall()

        perm = cur.execute('SELECT perm from users where login=?', [session['user']]).fetchone()
        if perm[0] == "Администратор":
            perm = True
        else:
            perm = False
        # Вызываем шаблон индекс, и посылаем в него имя пользователя и все поля таблицы месседж 
        return render_template('index.html', perm=perm, user=session['user'], thread=thread) 

    else:
        # Иначе возращаем пользователя на страницу ввода логина/пароля
        return redirect(url_for('login'), code=303) 

Можно заменить этим

@app.route('/') 
def root():
    if 'user' not in session:
        return redirect(url_for('login'), code=303)
    
    db = sqlite3.connect(DB)
    cur = db.cursor()
    thread = cur.execute('SELECT * FROM thread group by id order by date desc').fetchall()

    perm = cur.execute('SELECT perm from users where login=?', [session['user']]).fetchone()

    perm = perm[0] == "Администратор"

    return render_template('index.html', perm=perm, user=session['user'], thread=thread) 

Дальше попробуй сам.

А что, от такого кода ни у кого больше глаз не дергается?

        if perm[0] == "Администратор":
            perm = True
        else:
            perm = False

У меня задергался и я решил помощь переписать так

perm = perm[0] == "Администратор"

Твой код не лучше.

Предложи свой

Вообще тут лучше написать отдельный клас для работы с db тогда вьюшки еще более простые будут.

а если len(perm) == 0 ?

0. Подход вообще говно, я бы полностью переделал на нормальную ролевую модель, потому что текущий подход не расширяем. По факту сейчас есть только админ и обычный юзер, если нам завтра захочется добавить например модератора, или юзера с доп. правами, то этот код только выкинуть.

1. Оставаясь в рамках данного подхода, «роль» должна хранится в виде кода, который не меняется никогда, например 'ADMIN';

2. Выше уже правильно заметили, результат может быть пустым списком или None, это надо учитывать.

is_admin = perm is not None and 'ADMIN' in perm

perm = perm[0] == «Администратор»

я бы вообще отказался от идеи переопределят тип переменной. Сначала perm список, потом булево

perm[0]

надо проверять длину.

Стоит взаимодействие с БД вынести в отдельный модуль/файл и обернуть в ф-ции, тогда будет проще контролировать. И выпилить из репозитория файлы БД (*.db)

if 'user' in session: # Если пользователь в сессии
return redirect(url_for('admin'), code=303)

Я бы это превратил в декоратор

докину docker образ

язабан

Если работа с БД отделена от основного кода то несложно

я не программист
хоть у нас и физико-математические специальности, изучает программирование.

Что значит «хоть и» тут? Человек физмат специальности не умеющий в программирование это инвалид. Почти как писать/читать не уметь.

Ты вообще своим делом занят? Точно?

peewee ORM гораздо круче, если про объекты.

Почему нет, если там встроенная нормализация данных и пажинация?

А когда она не нужна? В хайлоаде? Фласк в нем не используют и так, что уж об ORM говорить.

Я пока не встречал щели где орм приносила больше пользы чем вреда.

Пажинация автоматом - неплохо, возможно будет полезно. А причем к ОРМ нормализация данных?

Т.е. вы согласны что ОРМ бывает вредна? Просто малость удивлен (перечитал ваше сообщение раза 3)

никто не мешает использовать ORM вкупе с «чистыми» SQL запросами. ORM которое не позволяет это сделать можно выкинуть на помойку

Когда она не нужна - на этот вопрос я ответить не могу. Когда без нее можно обойтись - на мой взгляд часто. Возможность быстро сменить базу данных на другую - весьма неплохо, но насколько часто это люди делают? Миграции - да, штука очень полезная, тут сказать нечего (но и без орм можно сделать что либо аналогичное). Возможность все писать и работать с данными на одном языке программирования, не затрагивая SQL - поначалу полезно, потом может стать вредно. Скорость работы и оптимальность запросов - поначалу может устраивать, но со временем может стать проблемой, с решением которой вы немало посидите. А если вас еще сложная выборка данных с нескольких таблиц (допустим штук 10 , с 5-7 колонок в каждой), и вам нужно данные отфильтровать/сгруппировать, да и чтобы работало быстро ... Скажем так, с обычным sql это будет сделать в разы проще. Я не претендую на звание гуру орм, но блин после того как я минут 30 просидел над тем, чтобы алхимия делала выборку данных более менее похожую на ту, что я делаю запросом, причем делала одним запросом, вытаскивая именно нужные мне данные - как то не ок стало мне. А это был один из простейших примеров. Да и скажем так - нередко видишь статьи «Мы использовали орм, у нас все работало хреново, мы налепили страшных престаршных архитектурно-програмных решений, и у нас вроде все заработало неплохо.». И самое главное, ты понимаешь, что при использовании обычного sql такие проблемы даже возможности возникнуть не имели бы.

Я имел ввиду доступ к связанным полям - уровень проработки и удобство.

Тогда глянь peewee. В ней ORM это объекты, а не драйвер к бд.

Views испоьбзовать не судьба ?

Честно говоря эту идею серьезно не рассматривал, казалась не совсем хорошей. Сейчас если подумать - вариант очень даже ничего. Правда не без нюансов.

На текущий момент peewee для меня не вариант, так как используется oracle.

почему ? Это все равно лучше пихать годлый sql в код

Т.е. вы согласны что ОРМ бывает вредна? Просто малость удивлен (перечитал ваше сообщение раза 3)

Все правильно. ОРМ хорошо разве что для любителя, который решил наколхозить бложик на джанге по туториалу с хабра, написаного таким же любителем.