Может показаться, что старый Yii1 в 2026 году уже никому не нужен. Но, на удивление, проектов, застрявших на этом фреймворке, довольно много. Чаще всего сдерживающими факторами от переезда являются размер проекта, какие‑то свои надстройки над фреймворком или отсутствие денег у бизнеса. Переезд сопряжён с рисками получить два проекта на годы вперёд. Параллельно требуются какие‑либо доработки, что требует вдвое больше ресурсов и от разработчиков, и от бизнеса.
Рубрика «orm»
Yii1: извлечение Active Record в отдельный composer пакет
2026-08-11 в 12:20, admin, рубрики: active record, composer пакет, orm, PHP 8.4, PSR-11, psr-14, PSR-16, yii1, миграция с Yii1, рефакторинг легасиЯ сделал ASGI-фреймворк, где дерево папок — и есть API
2026-07-24 в 11:36, admin, рубрики: asgi, backend, opensource, orm, python, Веб-разработка, фреймворкДавно преследует одна и та же боль в любом растущем API-проекте на Python: таблица маршрутов начинает жить своей жизнью. @app.post("/v2/user/role") лежит в файле, который импортируется через два уровня include_router, реальная бизнес-логика — в третьем файле, а понять «какой версии принадлежит этот эндпоинт» превращается в археологию по grep’у.
Я решил проверить гипотезу: а что если убрать таблицу маршрутов вообще? Не «сделать её удобнее» — а убрать как отдельную сущность. Пусть структура каталогов и будет таблицей маршрутов.
Так получился EndoCoreЧитать полностью »
Что будет, если убрать из ORM предположение «одна таблица — одна entity»?
2026-07-15 в 13:15, admin, рубрики: database, Design Thinking, library, orm, phpБольшинство ORM строятся вокруг естественного предположения: одной таблице соответствует одна entity. Это настолько привычно, что даже не обращаешь внимания.
Это не правило, но вокруг него проектируются почти все остальные механизмы: метаданные принадлежат классу, Unit of Work отслеживает экземпляры этого класса, миграции собираются из его описания, а объектная модель постепенно начинает повторять структуру базы данных.
При этом часто в коде не требуются все поля сразу. Конкретный процесс использует только то, что требуется, и ни читать, ни менять эти поля в других процессах не надо.
Я не хотел писать ORM для Kotlin-Native. Мне просто нужен был PostgreSQL
2026-06-22 в 14:13, admin, рубрики: dsl, kotlin, kotlin multiplatform, Ktor, mysql, native, orm, postgresql, sqliteВсе началось с архитектурного тупика. Я занимался бэкенд-частью low-code платформы, для автоматизации внутренних процессов крупных компаний. У платформы была жесткая специфика — обязательный и хардкорный оффлайн-режим. Пользователи — прорабы на удаленных строительных объектах и геологи в тайге, где связь пропадает не на пару минут, а на целые дни.
Приложение при этом должно полноценно жить локально: пользователь забивает данные, меняет статусы сущностей, генерирует документы, прикрепляет фото. А затем, когда появляется сеть, на бэкенд одновременно прилетает лавина накопленных синхронизаций.
Пишем свой SQL query builder на Python: DSL, кеширование в Redis и защита от инъекций
2026-04-30 в 8:15, admin, рубрики: asyncio, caching, django, dsl, orm, python, query cache, redis, sql, sql-инъекцияRoom или SQLite? Как не писать SQL запросы вручную на Android
2026-04-10 в 12:16, admin, рубрики: android, kotlin, orm, room, sqlite, базы данных, мобильная разработкаЕсли ты разрабатываешь под Android и нужно сохранять информацию на телефоне, без базы данных не обойтись. В системе есть встроенная SQLite — бесплатно и надёжно, но есть минус: чтобы с ней работать, приходится писать SQL-запросы вручную, в коде разбирать объект Cursor и не забывать закрывать соединения. Я сам сталкивался с тем, что из-за такой возни появляются баги и тратится много времени.
25 железных правил проектирования баз данных в PostgreSQL
2026-02-14 в 11:16, admin, рубрики: db, orm, PostreSQL, sqp, базы данныхКаждый, кто хоть раз разбирался в три часа ночи с упавшим продом, знает: большинство катастроф в базах данных это не сбой железа и не космические лучи. Это решения, принятые на этапе проектирования схемы. «Потом поправим», «в приложении проверим», «а зачем тут индекс?» каждая из этих фраз обходилась командам в часы даунтайма и миллионы потерянных строк.
Ниже 25 правил, которые я собрал из опыта работы с высоконагруженными системами. Это не теория из учебника — это грабли, на которые уже наступили до вас. Каждое правило сопровождается примером «как надо» и «как не надо», чтобы разница была наглядной.
I. Фундамент схемы
Немного о «Data Engeneering»
2025-10-20 в 14:15, admin, рубрики: .net, .net core, C#, orm, postgres, RabbitMQ, микросервисы, микросервисы и базы данных, нагрузка, согласованностьПоследние лет 5 работаю над сложными высоконагруженными системами, и хотел бы поделиться нюансами перехода из разработки голосовых роботов в финтех.
Первые два голосовых проекта в разных компаниях мы реализовывали на связках .Net + Asterisk с преобразованием TCP/GRPC трафика. Более интересен именно второй проект в этой области, где в полной мере использовалась микросервисная архитектура (тогда как на первом, в рамках стартапа, несмотря на задел под микросервисы с тз организации кода, у нас сильно проседал деплой).