что не так?

ну я лично считаю, что ORM — это сферический в вакууме образчик плохой архитектуры

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

не станет

до миллиона даже не дойдет

ну я лично считаю, что ORM — это сферический в вакууме образчик плохой архитектуры

++

но если использовать ORM, понимая, что count дорогой, то все нормально

?Осталось 25 мест, сегодня наша ВИП группа станет платной?

ORM в начале жизни проекта это хорошо. Преждевременная оптимизация - плохо

ну я лично считаю, что ORM — это сферический в вакууме образчик плохой архитектуры

Чего? ?

pyautogui.typewrite('hello world 123') выводит только цифры, язык системы менять не хочу, есть варианты что сделать?

ну я лично считаю, что ORM — это сферический в вакууме образчик плохой архитектуры

Эм. Не вижу причин отрицательно относиться к orm, сейчас всё на этом строится. Любой момент где ты данные получая из базы записываешь в класс можно уже смело называть orm. Если не так, то работать исключительно со строками и массивами?

Эм. Не вижу причин отрицательно относиться к orm, сейчас всё на этом строится. Любой момент где ты данные получая из базы записываешь в класс можно уже смело называть orm. Если не так, то работать исключительно со строками и массивами?

> Любой момент где ты данные получая из базы записываешь в класс можно уже смело называть orm Неверно.

Ну, по крайней мере я говорил об ORM в духе peewee и django ORM.

https://martinfowler.com/bliki/OrmHate.html Фаулер давно про это сказал уже

> Любой момент где ты данные получая из базы записываешь в класс можно уже смело называть orm Неверно.

идея ORM оборачивать данные из бд в объекты. Ну и упрощение получения/изменения/создания данных

идея ORM оборачивать данные из бд в объекты. Ну и упрощение получения/изменения/создания данных

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

Например, когда ты делаешь DAO, возвращающее тебе объекты, но модификации этих объектов не попадают неявно в базу.

Я кажется почти понял о чем ты. Модификация объекта != изменение базы. ORM сильно упрощает и разработку и чтение кода. Когда у тебя уже реализованы crud всё становится быстрее Если нужны сложные статистические запросы, то их тоже можно реализовать методами к твоим моделям и в них уже использовать SQL для читаемости.

ORM, как и все плохие архитектурные решения, упрощает разработку только поначалу (имхо).

Я кажется почти понял о чем ты. Модификация объекта != изменение базы. ORM сильно упрощает и разработку и чтение кода. Когда у тебя уже реализованы crud всё становится быстрее Если нужны сложные статистические запросы, то их тоже можно реализовать методами к твоим моделям и в них уже использовать SQL для читаемости.

ORM сильно упрощает и разработку и чтение кода Я бы этим поспорил. Например, неявные запросы в базу при получении атрибута объекта доставляют боль

ORM сильно упрощает и разработку и чтение кода Я бы этим поспорил. Например, неявные запросы в базу при получении атрибута объекта доставляют боль

Это претензия не к ORM как к идее, а к конкретной реализации

Это претензия не к ORM как к идее, а к конкретной реализации

Ну если принять что ORM это просто маппинг db-row -> object и обратно, то я пожалуй соглашусь

ORM, как и все плохие архитектурные решения, упрощает разработку только поначалу (имхо).

Вот этого без примера понять не могу. Допустим тебе в начале проекта orm упрощала жизнь. Значит у тебя там использовались какие-то crud действия. Что должно стать с проектом, чтобы тебе резко захотелось заменить эти круды на нативный sql и dao?

Начнём с того, что я могу захотеть прикрутить NoSQL-решения.

так не надо ОРМ вставлять напрямую во вьюхи

прячь реализацию запросов

так не надо ОРМ вставлять напрямую во вьюхи

а то что?

вьюхи не должны знать как там у тебя слой работы с БД устроен

это не их дело

ну то есть мы приходим к DAO всё равно?

так не надо ОРМ вставлять напрямую во вьюхи

+1

который для объектов в реляционных хранилищах использует ORM?

с этим вагон потенциальных проблем

/me вообще не понимает смысла в орм

который для объектов в реляционных хранилищах использует ORM?

вполне

все равно же я разделяю бизнес логику и персистенс слой на разные вещи

а между ними делаю трансляцию

потому что такой DAO будет первое время ривиальный

вполне

должен ли он возвращать объекты, отправляющие изменения атрибутов в БД?

в орм предполагается, что объекты бизнес логики строятся поверх объектов базы данных

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

так не надо ОРМ вставлять напрямую во вьюхи

++

должен ли он возвращать объекты, отправляющие изменения атрибутов в БД?

Хз

Хз

Но это важный вопрос. Если да, то мы всё равно получаем ORM. Если нет и ORM служит просто слоем генерации SQL-запросов — то это слишком сложное решение для такого слоя.

Всем привет. Собираю статистку в приложение на asyncio. Если просто, то на connaction_made - увеличиваю счетчик, на connection_lost - уменьшаю. Конекты не персистентные, это точно, отправил запрос (5-10кб). Вижу, что иногда не вызывается callback connection_lost периодически... Никто не сталкивался с этим?

И кто и как решал эту проблема, если встречались?

Использовал sqlalchemy, django-orm, go-pg, squirrel + sqlx. Здесь нет единого ответа плохо ORM или хорошо. Ну попробуйте мне без билдера собрать запрос с условиями в зависимости от переданных аргументов? И попробуйте с ORM решить узко-специфичные, например работа с jsonb в postgre, вещи? ORM и нужен и не нужен.

Я думаю такие большие и сложные вещи и данные вообще не должны выполняться сразу в онлайн при запросе клиента показать ему страничку. Django это интерфейс, для простых задач и логик там и описаны. Что то большое и сложно выносить за пределы django, тот же pyspark для обработки данных. С того же nosql. Чтобы интерфейс джанго тупо только брал и показывал данные с максимальной скоростью

Ну попробуйте мне без билдера собрать запрос с условиями в зависимости от переданных аргументов? А в чем тут проблема?

Ну попробуйте мне без билдера собрать запрос с условиями в зависимости от переданных аргументов? А в чем тут проблема?

подозреваю это будет немного некрасиво. конструирование строки запроса.

и менее читабельно

Использовал sqlalchemy, django-orm, go-pg, squirrel + sqlx. Здесь нет единого ответа плохо ORM или хорошо. Ну попробуйте мне без билдера собрать запрос с условиями в зависимости от переданных аргументов? И попробуйте с ORM решить узко-специфичные, например работа с jsonb в postgre, вещи? ORM и нужен и не нужен.

+ В большинстве случаев на проектах с которыми работал 95% запросов писались простеньким orm. Для сложых статистических запросов приходилось что-то допиливать вбивая sql/nosql запросы ручками, но и эти запросы оборачивались в orm в итоге возвращая объекты(без возможности изменения)

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

Не совсем верно выразился. Не без возможности изменения, а без возможности сохранения "изменений" в базу

Использовал sqlalchemy, django-orm, go-pg, squirrel + sqlx. Здесь нет единого ответа плохо ORM или хорошо. Ну попробуйте мне без билдера собрать запрос с условиями в зависимости от переданных аргументов? И попробуйте с ORM решить узко-специфичные, например работа с jsonb в postgre, вещи? ORM и нужен и не нужен.

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

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

Что-то на счет хранимок я не уверен

Ну и микросервисы тут вообще не в тему

Что-то на счет хранимок я не уверен

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

Данные отдельно, интерфейсы с пользователями отдельно.

Уважаемый автор поделки-бота "Vladimir Parkhomenko" тренеруйтесь где-нибуль в другом месте. Не забывайте правило "где ем, там не гажу".

И масштабировать удобно.

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

Т.е. у вас микросервисы в одну базу что ли ходят?

Ну и к деплою хранимок у меня большие вопросы

ERROR: S client not available

Т.е. у вас микросервисы в одну базу что ли ходят?

Микросервисы общаются друг с другом разными путями. Базы к сервисам привязаны. А на уровне базы и сервиса через оптимизированные процедуры или сторонние утилиты по обработки данных. На выходе django и подобные интерфейсы выдают данные без сложных обработок данных и логик.

А целесообразно парсить сайты на regexp?

нет

нет

А целесообразно парсить сайты на regexp?

Beatifulsoup

нет

А целесообразно парсить сайты на regexp?

https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags

я слишком долго искал ту ссылку

Микросервисы общаются друг с другом разными путями. Базы к сервисам привязаны. А на уровне базы и сервиса через оптимизированные процедуры или сторонние утилиты по обработки данных. На выходе django и подобные интерфейсы выдают данные без сложных обработок данных и логик.

Если у каждого микросервиса свои изолированная база, то откуда возьмется дублирование кода, по который ты выше писал?

я слишком долго искал ту ссылку

Да, это по-моему самый популярный ответ на SO

Ребята, подскажите, кто-то делал push-notifications для Gmail ??? Можно ли тестить с ngrok, или обязателюно регать и подтверждать домен?

Если у каждого микросервиса свои изолированная база, то откуда возьмется дублирование кода, по который ты выше писал?

Про микросервисы написал, это к разделению, вынесения кода от основного. Ну дам пример. От задачи зависит. Некоторым сначала нужен сайт. Они пишут и все внутри сайта пихают. Потом им понадобилось мобильное приложение. И конечно лучше писать api, но по ТЗ там используют тоже прямое подключение к базе. И где начинаются дубли логик. Потом часто банкомат, терминалы, веб версия, разные приложения работают с определёнными базами.

Так regexp-ы же должны очень даже быстро работать?

Про микросервисы написал, это к разделению, вынесения кода от основного. Ну дам пример. От задачи зависит. Некоторым сначала нужен сайт. Они пишут и все внутри сайта пихают. Потом им понадобилось мобильное приложение. И конечно лучше писать api, но по ТЗ там используют тоже прямое подключение к базе. И где начинаются дубли логик. Потом часто банкомат, терминалы, веб версия, разные приложения работают с определёнными базами.

Я почти ничего не понял. Можешь ответить на два простых вопроса (да/нет): 1. Может ли одна база использоваться двумя микросервисами? 2. Могут ли хранимки изменятся с breaking changes?

Так regexp-ы же должны очень даже быстро работать?

1. В питоне регекспы работают за экспоненциальное время. 2. HTML не является регулярным языком, поэтому корректно распарсить его регэкспами математически невозможно.

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

и сделать из этих кусков xhtml

я такое делал

Токенизировать возможно, да. Вряд ли это имеется в виду.

Я почти ничего не понял. Можешь ответить на два простых вопроса (да/нет): 1. Может ли одна база использоваться двумя микросервисами? 2. Могут ли хранимки изменятся с breaking changes?

1. Да, конечно; 2. Не понял вопроса. Главное чтобы входные и выходные данные не менялись. Видимо не понимаю о чем речь

ну да

после токенизации уже обработка идет вручную

1. Да, конечно; 2. Не понял вопроса. Главное чтобы входные и выходные данные не менялись. Видимо не понимаю о чем речь

1. Да, конечно Теперь понятно откуда в разных сервисах может дублироваться код Главное чтобы входные и выходные данные не менялись Что делаете когда их все-таки надо менять? Версионируете процедуры?

1. Да, конечно Теперь понятно откуда в разных сервисах может дублироваться код Главное чтобы входные и выходные данные не менялись Что делаете когда их все-таки надо менять? Версионируете процедуры?

Да новая версия процедуры. Как и поддержка старых методов должна оставаться. Потому как с ней могут работать старые приложения которые ещё не обновились отдавать и получать другое количество данных.

Сложность когда слишком много разработчиков разных, и приложений и все работает со всеми. В том числе через rest api. Версии нужно сохранить.

1. Да, конечно Теперь понятно откуда в разных сервисах может дублироваться код Главное чтобы входные и выходные данные не менялись Что делаете когда их все-таки надо менять? Версионируете процедуры?

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

Php шники не поймут, как иногда сложно постоянно или периодически обновлять приложение. У них напрямую по фтп код поправил и готово ничего страшного.

Да новая версия процедуры. Как и поддержка старых методов должна оставаться. Потому как с ней могут работать старые приложения которые ещё не обновились отдавать и получать другое количество данных.

С версионированием понятно. Но я все равно не очень понимаю какой профит дают общие (для нескольких микросервисов) хранимые процедур по сравнению с их взаимодействием через API

/me считает, что хранимые процедуры не нужны

С версионированием понятно. Но я все равно не очень понимаю какой профит дают общие (для нескольких микросервисов) хранимые процедур по сравнению с их взаимодействием через API

В частности нужно на проект смотреть. Микросервис может работать с файлами, изображениями. Спрашивает что то у базы. А сам сервис выдаёт все по api конечному приложению который дёрнул сервис.

С версионированием понятно. Но я все равно не очень понимаю какой профит дают общие (для нескольких микросервисов) хранимые процедур по сравнению с их взаимодействием через API

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