Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
def __get_column_names(table: str) -> tuple:
try:
with conn:
cur.execute("SELECT name FROM PRAGMA_TABLE_INFO(?)", (table,))
column_names = cur.fetchall()
except Exception as excpt:
print(excpt)
column_names = tuple(i[0] for i in column_names)
return column_names
def db_register_user(user_data: types.User):
"""
SQL запрос для внесения данных о пользователе
Args:
user_data: telebot User объект, содержащий словарь с параметрами пользователя
"""
user_data = user_data.to_dict()
column_names: tuple = __get_column_names('Users')
user_values = tuple(user_data.get(key) for key in column_names if key in user_data)
try:
with conn:
query = 'INSERT INTO Users cn'.replace('cn', str(column_names))+' VALUES (?,?,?,?,0,3)'
parameters = (*user_values,)
conn.execute(query, parameters)
except Exception as excpt:
print(excpt)
conn.close()
На сколько в такой ситуации .format не безопасен? Идея в том, чтобы не объебошится программисту в коде введя неверное значение колонки. Для этого имена колонок берутся из самой базы (есть мысль ещё и типы брать). Есть вариант реализации получше? Спасибо
Почему не делать-то? Таким образом я могу сделать универсальную функцию, которая каждый раз будет давать корректные имена из самой бд. Если бы я понимал, почему так лучше не делать (по твоим словам), я бы не постил это сюда)
This. И да, белым людям после этого тайпчекер («mypy»/«pyright»/«pylance») проверяет типы колонок и удостоверяется, что белый человек не присвоил не то не тому, а IDE — подсказывает названия и подчёркивает опечатки.
Схема данных это самое важное что есть в твоем коде. Из нее ты строишь модели, из них проектируешь API. Общее правило - ты всегда подстраиваешь код приложения под бд, не наборот.
Проблемы с твоим подходом:
1) Ты делаешь два запроса в бд когда можно делать один. Это увеличивает время обработки запроса и больше потенциальных точек отказа.
2) У тебя захардкожено 4 параметра в кверю если я правильно понимаю, то есть тебе все равно придется менять это место в коде когда захочешь поддерживать новую колонку.
3) Если ты будешь добавлять новые колонки не строго в конец таблицы, то рано или поздно ты знапишешь что-то не так. С твоим подходом, ты в принципе сильно повышаешь вероятность что-то записать не так.
4) Именнованные параметры намного лучше читаются в логах или инструментации твоей бд.
>Общее правило - ты всегда подстраиваешь код приложения под бд, не наборот.
Есть и другой подход. Скажем, EF умеет генерировать схему по коду, но как правило схема получается не очень.
А например в Django модель хоть и описываеца на питоне, но всё равно четко отражает СУБД
> Общее правило - ты всегда подстраиваешь код приложения под бд, не наборот.
Опровергаю. Есть бизнес-контракты, требования к самому приложению, есть апи, которое оно должно предоставлять. Обычно оно выражается в каких-то структурах-объектах и сервисах. И вот уже от них пляшет вообще всё остальное.
Говно ебаное ваш Uber.
Пол часа переписываешься с водителем, который хочет назначить цену выше, чем в приложении, в итоге соглашается как есть, либо уезжает нахуй, не отменяя заказ.
Если приезжает, то ты садишься в машину и он отменяет заказ, чтобы я ему рейтинг хуёвый не въебал. А рейтинг у водителя 5.0, хуле.
Ещё делюсь лайфхаком, если пассажир платит наличкой.
Получаешь X$ от пассажира наличкой. А в приложении отмечаешь, что пассажир дал X$-5$. 5$ — твой заработок с нихуя, а у пассажира долг.
А если долг выше какого-то порога, то его нельзя оплатить наличными при следующей поездке и в самый неподходящий момент (нужно ехать в аэропорт, например) выясняется, что тебе отказывают в обслуживании до погашения долга.
Вообще я планировал совместить с заездом к пацанам в дельфт, но они сами завтра приезжают. Середина сентября было бы норм, но если горит, то можно и раньше.
По ходу действия романа он несколько раз пытается помочь окружающим: парню, с которым познакомился в тюрьме (тот оказался там за попытку заняться сексом с арбузами фермера);
Серьезно, не нужно делать кривое квадратное колесо
https://docs.djangoproject.com/en/4.1/topics/db/models/
Проблемы с твоим подходом:
1) Ты делаешь два запроса в бд когда можно делать один. Это увеличивает время обработки запроса и больше потенциальных точек отказа.
2) У тебя захардкожено 4 параметра в кверю если я правильно понимаю, то есть тебе все равно придется менять это место в коде когда захочешь поддерживать новую колонку.
3) Если ты будешь добавлять новые колонки не строго в конец таблицы, то рано или поздно ты знапишешь что-то не так. С твоим подходом, ты в принципе сильно повышаешь вероятность что-то записать не так.
4) Именнованные параметры намного лучше читаются в логах или инструментации твоей бд.
Есть и другой подход. Скажем, EF умеет генерировать схему по коду, но как правило схема получается не очень.
А например в Django модель хоть и описываеца на питоне, но всё равно четко отражает СУБД
- graphql вроде так же делает
Опровергаю. Есть бизнес-контракты, требования к самому приложению, есть апи, которое оно должно предоставлять. Обычно оно выражается в каких-то структурах-объектах и сервисах. И вот уже от них пляшет вообще всё остальное.
Ты можешь сделать АПИ сервиса леера в бизнес-терминах, а слой доступа к базе в терминах базы, а потом их склеить, не?
В продуктовой разработке ничего этого нет. Именно потому я за продуктовую разработку.
Сам как?
теперь или я не тот, или этого стало меньше
Субкультуры позже найду
Дискуссии позже найду
Пол часа переписываешься с водителем, который хочет назначить цену выше, чем в приложении, в итоге соглашается как есть, либо уезжает нахуй, не отменяя заказ.
Если приезжает, то ты садишься в машину и он отменяет заказ, чтобы я ему рейтинг хуёвый не въебал. А рейтинг у водителя 5.0, хуле.
Дайте угадаю. Рейтинг состоит из единственной оценки?
Получаешь X$ от пассажира наличкой. А в приложении отмечаешь, что пассажир дал X$-5$. 5$ — твой заработок с нихуя, а у пассажира долг.
А если долг выше какого-то порога, то его нельзя оплатить наличными при следующей поездке и в самый неподходящий момент (нужно ехать в аэропорт, например) выясняется, что тебе отказывают в обслуживании до погашения долга.
> твой заработок с нихуя, а у пассажира долг
– и сколько раз прокатывает такой фокус?
Почему-то карту мою не принимал.
> и сколько раз прокатывает такой фокус?
Сколько угодно раз. Ведь в поддержку даже пожаловаться нельзя.
Uber — говно ебаное. Это вам не "Яндекс.Такси", где водителя бы выебали за это.
– что, простите
Не, я понимаю, что она там в приложении на уровне автоответчика, но вроде ж есть пункт "возникла проблема с поездкой"
но вообще в уберах у водилы больше вариантов кинуть пассажира, чем наоборот, это да
(нас тут двое кстати из-под геста пишет, если что)
Waaneer kan je naar Asmterdam?
Но я не принимаю уже больше трёх лет
Они тупо не работают
Те, кого комиссовали после ранения?