Прочитал статью Фамильный вики-движок Bonsai: 6 лет спустя и вспомнил что в своё время были планы сделать что-то подобное. После того как я попробовал использовать некоторые существующие решения (особенно одно в котором предлагалось при добавлении человека указать кем он является по отношению к другим и список на 100500 позиций вида сын, дочь, мама, папа, дедушка и т.д. и т.п. ) была разработана собственная схема хранения родственных связей в виде графа. В качестве вершин графа выступают люди, а в качестве ребер отношения между людьми. При этом типов отношений всего два:
Родитель->Ребенок (связь имеет направление от родителя к ребенку)
Брачный союз (связь равноправна и не имеет направления)
С помощью отношений этих двух видов возможно задать родство любой сложности.
В век когда ORM шагает по планете обычный построитель запросов выглядит откатом назад. Однако тут есть нюанс — Sql Query Builder использует пакет версионированияshasoft/db-schema и владеет всей информацией о структуре базы данных. Это позволяет реализовать все стандартные для таких решений функции, прозрачно конвертировать типы данных SQL<=>PHP + реализовать нестандартные возможности в виде выборки данных с использованием КЭШирования. (Просьба не искать логику в SQL запросах в статье и примерах, её там нет. Искусственные примеры предназначены для демонстрации возможностей пакета и никакой другой смысловой нагрузки не несут).
Всегда немного раздражало что при написании миграций в Laravel сначала необходимо прописывать поля в классе модели, а затем эти же поля в миграциях. И когда мне понадобилось написать версионирование структуры БД, то решил совместить класс модели и миграции. И сделал я это через атрибуты PHP. Также вместе с миграциями я получил состояние базы данных с мета-информацией которую можно использовать при работе с ней.
Прошлая статья по данной теме была чисто теоретическая. Теперь есть готовый пакет. И данная статья - инструкция к нему.
Базовый функционал Самое очевидное применение группировки вызовов - решение проблемы N+1 запросов. Данная проблема возникает когда фреймворк доступа к данным выполняет N дополнительных SQL-запросов для получения тех же данных, которые можно получить при выполнении одного запроса. К примеру для получения данных имеются вызовы следующих функций, каждая из которых выполняет один SQL-запрос. При применении пакета 6 вызовов функций группируются в две группы по типу функции вызова. И в каждую группу попадают все аргументы вызова.
Проблема N + 1 возникает, когда фреймворк доступа к данным выполняет N дополнительных SQL-запросов для получения тех же данных, которые можно получить при выполнении одного SQL-запроса.
Обычно это решается с помощью ленивой загрузки. В статье разбирается вариант с асинхронной группировкой вызовов.
Я писал ранее статью Генерация API сайта на основе заданных пользователем функций, однако информация там была о конечной реализации (к тому же теоретической), и, ожидаемо, никто не понял для чего это вообще нужно. Поэтому попробую расписать это с другой стороны: от задачи к её решению через генерируемое в Samoyed CMG API.
Описание задачи
Пусть у нас есть небольшой сайт со списком статей с пагинацией. Статьи пишут пользователи сайта.
На главной странице выводим список последних 10 статей. В списке заголовок и автор. При нажатии на заголовок выводится страница с выбранной статьёй. На странице статьи выводится заголовок, содержимое + автор.
Простейшая схема таблиц базы данных представлена ниже.
В прошлой статье был описан процесс установки и запуска Samoyed CMG (Content Management Generator). Основная идея — генерация кода сайта на основе настроек заданных кодом. Т.е. фактически кэширование всех настроек в коде при генерации, а не при развертывании на хостинге.
В ней упоминались генераторы для генерации кода, которые служат для расширения базового функционала сайта. В примере представлены два из них:
В прошлой статье была описана теория CMG (Content Management Generator). Основная идея — генерация кода сайта на основе настроек заданных кодом. Т.е. фактически кэширование всех настроек в коде при генерации, а не при развертывании на хостинге.
В данной статье описан процесс установки и генерации тестового сайта. Итоговый сайт и код примера прилагается. Также сайт содержит страницу с технической информаций (картинка именно оттуда).
Основная идея CMG (Content management generator) — не выполнять в Runtime то, что можно сгенерировать в виде статического PHP кода. Т.е. мы кэшируем все данные в генерируемом коде. Это происходит во всех современных фреймворках, но в данном случае это происходит не при развертывании на хостинге, а при кодогенерации. Код сайта генерируется с помощью конфига в виде кода. На мой взгляд для программиста это удобнее + больше гибкости чем при работе с конфигом.
Если создать в интернете базу данных всех существующих файлов, то любой архив будет представлять собой список имен каталогов, файлов, дата+время изменения/создания и хеши этих файлов. А при распаковки архива достаточно будет просто скачать из интернета содержимое файла по его хешу, записать на диск и присвоить атрибуты (дата,время). Т.е. даже архив с полным сезоном какого-нибудь сериала из 20 серий будет занимать не больше нескольких килобайт (в независимости от качества видео).
Идея достаточно простая: в определенной директории задаётся API функция в виде файла php которая возвращает анонимную функцию. Функции могут быть четырех типов: Put (изменение значений), Get (кеширование до изменения зависимостей), LifeTime (кеширование по времени), Direct (прямой вызов). При этом в функциях типа Get кешируют своё значения до вызова соответствующего значения Put.
Предлагаю вашему вниманию статью с алгоритмом преобразования правила файла .gitignore в регулярное выражение. Общий алгоритм с возможностью реализации на любом языке программирования. Если кто-то хочет вставить в свою программу правила игнорирования git, то эта статья для вас.
