Комментарии 20
А вы уверены что это статья?
Мне кажется это просто код с отсебятиной автора в комментариях
Мне кажется что нет. Перед написанием этой статьи мне посоветовали поменьше объяснений и больше кода, т.к. все таки здесь продвинутое сообщество.
т.к. все таки здесь продвинутое сообщество.
Давно уже тут полно домохозяек
Домохозяйки тут не причем. Какая полезность этого кода? Вы бы стали использовать эту orm или взяли бы алхимию?
Но все равно, костяк остается. Домохозяек много, но они в основном идут либо на популярные статьи, либо на простые. И то, часть из них не являются активными пользователями хабра. Но это мое мнение, если что.
а зачем такое выкгадывать на хабре? для галочки?
Пара замечаний:
Исходники портянкой на хабре, наверное, перебор.
Существует стандартная практика - ссылка на GitHub или любой другой публично доступный Version Control System ресурс.Если уж вы создаете ORM со своими типами данных, то наверное нужно расширить типы данных, добавив поддержку стандартных Date, DateTime и др. фишек, типа Enumerations.
Это только у меня строковый тип поля "SlugField" вызывает подтормаживание - что за новое именование?
Выглядит хорошо, я тоже недавно задавался вопросом, а как сделать entity cache в orm (если что, еще не сделал, но я верю в свой путь), мне очень помогло чтение кода Hibernate (но там правда, очевидно, java) и неплохо этот вопрос описан у Фаулера (Patterns of Enterprise Application Architecture - Martin Fowler) в 11 главе. Там и про Unit of work и про Identity map по отдельности.
По поводу кучи кода, я читал без проблем, некоторые замечания:
как по мне лучше вычистить для статьи комментарии вида
commits changesдля функцииcommitможно поудалять бойлерплейт и заменить на комменты вида
доказательство теоремы оставим как упраженение читателю=)убрать импорты, если они не критически важны для понимания, т.к. они просто забивают пространство
убрать имплементацию длинных функций, если нет цели описать алгоритм внутри этих функций; если я правильно понял, одна из целей - сделать сложную OOP структуру, то для рассказа о такой структуре можно фокусироваться на классах и их связях (через поля, методы и т.п.. ну и запихать весь код в статью, можно наверно в начале проекта, но потом он перестанет туда умещаться >_<
Будет здорово, если продолжите делать, когда дойдете до one-to-many, many-to-many, many-to-many with extra columns, multicolumn primary key, начнете чувствовать легкое жжение, не обращайте внимание =)
Не рекомендую следовать данному гайду, я так 6 лет назад тоже написал свою ORM (tortoise) - до сих пор приходится поддерживать и фиксить баги (:
https://github.com/ManyakRus/crud_generator
У меня ещё лучше - автоматически создаётся полностью готовый микросервис с функциями CRUD операций (Create, Read, Update, Delete), а также работа всех функций по протоколу GRPC.
Генерируется исходный код для каждой таблицы и колонки в БД.
Заполнить надо только настройки подключения к БД, больше не надо ничего заполнять(настраивать), можно и настраивать, изменять имена каталогов и др.
крутая статья, много кода. Но хотелось бы чтобы код был скрыт под спойлеры, и побольше объяснений об ООП моментах
Можно ли было метакласс заменить на дескрипторы? И зачем прибивать гвоздями сторонний логгер?
Странная статья. Создание уникального индекса названо параметром типа. А в следующем же абзаце параметром поля. Про сами индексы вообще ничего не сказано
Код даётся просто стеной, как он есть, без пояснений как он работает
Вместо сырых SQL-запросов мы будем использовать классы для выборки, фильтрации и получения записей
А в чём преимущество записи QueryBuilder().SELECT("*").FROM(User.table_name).WHERE(name="Anna")
по сравнению с обычным SELECT * FROM User WHERE name = 'Anna' ?
Создаем свою ORM на python — гайд