Челендж на 2026

А это как раз элемент магии. UserTable имеет описание для всех столбцов (по сути массив). Может быть посмотрю, что под капотом позднее.

Эти две недели "пожинал" плоды пропуска этапа проектирования.

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

В том числе провел рефкторинг структуры проекта (при этом фреймворк хоть и учебный, но обратную совместимость сохраняю до следующей мажорной версии). 

Реализовал систему сервиспровайдеров, для удобной интеграции модулей и сервисов (в т.ч. и потенциальными пользователями). При этом тут уже есть точка сравнения  с тем же ларавел.  У меня строится граф зависимостей и сервиспровайдеры загружаются в порядке согласно задекларированных ими зависимостей. (с защитой от цикличности)

Так же сделал и систему загрузки окружения и конфигов. И сделал на основе конфиг файлов возвращающих массив, но вчера решил поступить иначе - конфигурации будут организованны на объектах, что позволит использовать типизацию, избавит от возможностей опечаток (в ключах массива), а так же поможет в IDE с теми же подсказками какие параметры есть. Т.е. тоже еще одна точка для сравнения.

В общем у меня все движется. Но релиза еще нет. Состояние на данный момент в ветке next

ArbNet у тебя есть движение?

Буквально вчера получил новый комп. Начал его настраивать для работы, сегодня может донастрою.

Что касается разработки, у меня всё ещё в зависшем состоянии. Когда ты тут обсуждал создание формирования запросов к бд я хотел написать, что то как ты хочешь сделать, как тогда давно мне говорил, мне не подходит. Я сделал свой класс для запросов, но при создании страниц сайта понял, что это будет полная лажа..

$user = UserTable::query()
  ->addSelect('name')
  ->addSelect('id')
  ->where('lastname','Petrov')
  ->fetchObject();

echo $user?->getName();

Во-первых, я стремлюсь сделать работу кода быстрым и без верёвочных подходов говнокодинга(типа удобно, но в работе это замедление и куча лишних телодвижений..). То есть если рассматривать класс для формирования запроса у которого куча методов для указания параметров, то это время на передачу этих параметров в класс, а потом на их обработку. По-моему это глупый и тупой подход, когда проще и лучше написать сразу готовый запрос. Во-вторых, у меня для работы с фреймворком несколько уровней порога: новичок, опытный и разработчик. Для новичков буду делать визуальный редактор аля-тильда, опытный сможет на xml создавать сам странички, а разработчик уже будет разрабатывать разные компоненты с php классами(в которых писать и запросы к бд без танцев с бубном типа query builder работу с которым надо объяснять пользователю), скриптами, разметкой, css и js.

ЗЫ. Поэтому я переделаю такую работу с бд. На этом и застрял, долго обдумывал. Есть пока только мысли как реализовать, я сделаю упрощённый класс в котором будут готовые запросы(без хрени выше в цитате). Донастрою комп, буду переделывать это.

Ну тут такое. все зависит от сложности и логики генерации запросов.  Если количество ограниченно, и они заранее известны или тривиальны, то может быть, да и то с условием, что мы гарантированно не будем менять хранилище данных. (а это вполне себе реальная задача, у меня, например, на одном из проектов часть таблиц поехала в БД другого типа).

А так... ну представим запрос

    SELECT 
        o.id AS order_id, 
        o.total_amount, 
        o.created_at, 
        u.name AS user_name, 
        m.name AS manager_name
    FROM orders o
    INNER JOIN users u ON o.user_id = u.id
    LEFT JOIN users m ON o.manager_id = m.id
    WHERE u.status = 'active'
      AND u.city IN ('Москва', 'Санкт-Петербург')
      AND o.status != 'return'
      AND o.id IN (
          SELECT id 
          FROM orders 
          WHERE user_id = u.id 
            AND status = 'paid' 
            AND created_at > DATE_SUB(NOW(), INTERVAL 1 MONTH)
      )
    GROUP BY o.id, u.name, m.name
    HAVING COUNT(o.id) >= 1
    ORDER BY o.created_at DESC
    LIMIT 5

т.е. если тут же его реализовывать то будет так (пока только само формирование запроса)

$queryBuilder
    ->select([
        'o.id as order_id', 
        'o.total_amount', 
        'o.created_at', 
        'u.name as user_name', 
        'm.name as manager_name'
    ])
    ->from('orders', 'o')
    ->join('users', 'u', 'o.user_id', '=', 'u.id')
    ->leftJoin('users', 'm', 'o.manager_id', '=', 'm.id')
    ->where('u.status', '=', 'active')
    ->whereIn('u.city', ['Москва', 'Санкт-Петербург'])
    ->where('o.status', '!=', 'return')
    ->whereExists(function ($q) use ($queryBuilder) {
        return $q->selectRaw('1')
                 ->from('orders')
                 ->whereColumn('user_id', 'o.user_id')
                 ->where('status', '=', 'paid')
                 ->where('created_at', '>', now()->subMonth());
    })
    ->groupBy(['o.id', 'u.name', 'm.name'])
    ->havingRaw('COUNT(o.id) >= 1')
    ->orderBy('o.created_at', 'DESC')
    ->limit(5)
    ->getQuery();

и далее особенности возникают нюансы. Что если нам требуется событийная модель и запрос у нас формируется в разных местах.

т.е у нас

$query = $queryBuilder
    ->select([
        'o.id as order_id', 
        'o.total_amount', 
        'o.created_at', 
    ])
    ->from('orders', 'o')
    ->where('o.status', '!=', 'return')
    ->groupBy(['o.id'])
    ->havingRaw('COUNT(o.id) >= 1')
    ->orderBy('o.created_at', 'DESC');
Event::send(new OrderSelectEvent($query));

$query->getQuery();

И слушатели событий, если сочтут необходимым, достраивают этот запрос. Как с "готовыми" запросами такие решать задачи? А ведь это фреймворк, т.е. инструмент для решения любых задач.

Вы про подготовленные запросы по ходу не знаете.. Вот когда у чела нет знаний и опыта, то он и говорит о всяких запечённых запросах и тп.. вот вам и лол..

Так в том то и суть, что в твоём классе формирования запросов не будет гибкости это раз. Не все подобные сложные запросы сможешь реализовать таким способом, да и ещё потеря времени на их формировании сначала добавляя команды и параметры, а потом сам запрос.. это два.

ЗЫ. Короче делайте как умеете;)