Простота этого решения обманичива. Всегда не хватает для плагина, того или иного сигнала, чтобы генерировала система, приходиться все равно править ядро. К тому же очень часто нужно выбирать когда вызывать слот, до события или после (до вставки записи в БД или после), а все это породить множестные вызовы emit, там где надо и там где не надо (а вдруг понадобиться для плагинов)
Еще один минусом можно считать то, что отлаживать подобный код сложнее, если ошибка возникает во время генерации события, потому что не сразу видно все навешанные обработчики.
Данное решение более полезно там, где система «стоит» в ожидании внешних факторов. Будь то пользовательский интефейс, либо самописный http-сервер.
Немного почитал доки, и сложилось впечатление что я где-то похожее уже видел.
Когда разработчики будут предлагать что-то революционно новое, а не копировать друг у друга идеи?
Я бы лично перешел на другой framework если бы он действительно чем то новым. Аргументы «работает быстрее» либо для меня ничего не значат. Кто хочет быстрее, пусть пишет на С.
Может настало время 2.0 фреймворков?
Вот пара идей:
- веб-интерфейс по генерации скелета приложения
чтобы без консоли, консоль пусть будет для тех кто привык.
- веб-интрефейс по конфигурированию
чтобы не править файлы, а все с подсказками, и с возможными вариантами опций.
- веб-интрефейс создания моделей
вбил пару сток, а тут таблица в базе нарисловалась. Поменял связи - автоматически запустились alter'ы
- веб-интрефейс по локализации
показывался прогрес бар для файлов и прочие вкусности.
Я с таким «решением» сталкиваюсь каждый день на работе.
При очевидных плюсах (добавление/удаление свойств) я получил кучу минусов.
Первый затык встал на проверке входных данных. Пришлось писать «общую» форму для редактирования стойств объектов (здесь я имею ввиду указать длину, выставить цвет), для того чтобы проверки свести в одно место.
Но потом выяснилось что, товар «А» может быть зеленый и черный, а товар «B» черный, розовый и синий. Проверка превратилось в «непереводимую игру букв»
Второй затык встал при поиске. На каджое условие пользователя приходилось делать inner join, а кол-во условий доходило до 20 (значение как правило %Mobile%, которые не позволяли использовать индексы)
Вот таких «затыков» еще было много, но мне их здесь не описать, они достаточно часные.
Все это объясняется «универсальностью» предложенного метода, а если возникает какое-нибудь часное правило, можно смело иди вешаться.
Каждое решение имеет право на существование. Гораздо ценее было бы описать плюсы и минусы всех подходов, чтобы читатель мог применить то решение, которое ему более подходит.
Я имел виду, что для ручек одна таблица, для карандашей своя, для резинок третья.
А если захочется сравнить, что дороже: ручка, карандаш или тетрадка — это же какой громоздкий запрос с UNIONами получится.
Надо смотреть глубже в архитектуру приложения. Если такое подразумевается (сравнивать карандаши и ручки), тогда бы я вынес общие свойства в отдельную таблицу «товар» (с ценой и цветом, напрмер). Получается некое наследование свойств.
Я тоже предлагаю решение. Мне главное понять как лучше. Поехали.
1. Не знаем по каким полям будет идти поиск -> По всем
2. "… забавно будет посмотреть на то как вы будите по 1500 или 5к (это количество разных видов товаров) делать поиск по ограничивающему параметру..."
Стоп! Одинаковые свойства у разных товаров? Это типа: «Найти бампер и фару стоимосью до $30», так чтоли? Я ищу либо бампер либо фару. Или я Вас не понял.
3. Про «второй момент» не понял, можете пояснить, кто получает выйгрышь?
И еще. Сравните два sql. Необходимо найти Масло до $30 и либо Mobil либо Castrol.
SELECT * FROM objects t
INNER JOIN int_property t2 ON t.id = t2.object_id AND t2.prop_id = 101 /* это цена */
INNER JOIN string_property t3 ON t.id = t3.object_id AND t3.prop_id = 102 /* тип масла */
INNER JOIN string_property t4 ON t.id = t4.object_id AND t4.prop_id = 102 /* тип масла */
WHERE t2.value < 30
AND (t3.value = 'Castrol' OR t4.value = 'Mobile')
====
SELECT * FROM oil
WHERE price < 30
AND (type = 'Castrol' OR type = 'Mobile')
Универсальность зло. Вы не только в скорости проигрываете, но и в «простоте» приложения.
Что может быть «с переменным кол-вом свойств»? Например, добавление нового товара в каталог Интернет-магазина, где он добавляется/редактируется через панель. Думаю у вас что-то похожее.
Так вот, я бы сделал на каждый товар по таблице. А в админке запросы пользователя переводил на alter'ы (редко товар меняет свойство, соврее добавляет новые);
Так скрость возрастет, база станет более «понятной», упрастяться sql;
А если идти вашим подходом, то в конечном итоге так всю базу можно запихать в одну таблицу (id, var_name, var_value)
select *
from blog
inner join (
select
from comment
where blog.id = comment.blog_id
order by comment.date_created desc
limit 10
) as comment on comment.blog_id = blog.id
where blog.type = 3
order by blog.date_created desc
limit 10
Но задача «не живая», на практике за такое надо по пальцам бить и отдельные сущности выбират разными запросами
Посмотрел описание установки и удивился. Никакой не simple…
У некоторых нет доступа до консоли на хостинге.
Может стоило заранее запустить генерацию и уже представить результат?
Реальный результат на продакшене будет другой. У вас с базой 1 пользователь работает?
Т. к. у sqlite один файл на все таблицы, то при записи будет блокировка ВСЕЙ базы, и во время параллельных запросов на запись отставание sqlite будет очевидным. У MySQL блокировка может быть на уровне таблиц или строк.
Еще один минусом можно считать то, что отлаживать подобный код сложнее, если ошибка возникает во время генерации события, потому что не сразу видно все навешанные обработчики.
Данное решение более полезно там, где система «стоит» в ожидании внешних факторов. Будь то пользовательский интефейс, либо самописный http-сервер.
Идея в том, чтобы добавить frontend к фреймворку, для удобного управления.
Scaffolding модуль уже есть в некоторых продуктах, нужно лишь развивать идеи.
Когда разработчики будут предлагать что-то революционно новое, а не копировать друг у друга идеи?
Я бы лично перешел на другой framework если бы он действительно чем то новым. Аргументы «работает быстрее» либо для меня ничего не значат. Кто хочет быстрее, пусть пишет на С.
Может настало время 2.0 фреймворков?
Вот пара идей:
- веб-интерфейс по генерации скелета приложения чтобы без консоли, консоль пусть будет для тех кто привык. - веб-интрефейс по конфигурированию чтобы не править файлы, а все с подсказками, и с возможными вариантами опций. - веб-интрефейс создания моделей вбил пару сток, а тут таблица в базе нарисловалась. Поменял связи - автоматически запустились alter'ы - веб-интрефейс по локализации показывался прогрес бар для файлов и прочие вкусности.При очевидных плюсах (добавление/удаление свойств) я получил кучу минусов.
Первый затык встал на проверке входных данных. Пришлось писать «общую» форму для редактирования стойств объектов (здесь я имею ввиду указать длину, выставить цвет), для того чтобы проверки свести в одно место.
Но потом выяснилось что, товар «А» может быть зеленый и черный, а товар «B» черный, розовый и синий. Проверка превратилось в «непереводимую игру букв»
Второй затык встал при поиске. На каджое условие пользователя приходилось делать inner join, а кол-во условий доходило до 20 (значение как правило %Mobile%, которые не позволяли использовать индексы)
Вот таких «затыков» еще было много, но мне их здесь не описать, они достаточно часные.
Все это объясняется «универсальностью» предложенного метода, а если возникает какое-нибудь часное правило, можно смело иди вешаться.
Смотрите ниже, для «общих свойств» одна отдельная таблица.
А если захочется сравнить, что дороже: ручка, карандаш или тетрадка — это же какой громоздкий запрос с UNIONами получится.
Надо смотреть глубже в архитектуру приложения. Если такое подразумевается (сравнивать карандаши и ручки), тогда бы я вынес общие свойства в отдельную таблицу «товар» (с ценой и цветом, напрмер). Получается некое наследование свойств.
1. Не знаем по каким полям будет идти поиск -> По всем
2. "… забавно будет посмотреть на то как вы будите по 1500 или 5к (это количество разных видов товаров) делать поиск по ограничивающему параметру..."
Стоп! Одинаковые свойства у разных товаров? Это типа: «Найти бампер и фару стоимосью до $30», так чтоли? Я ищу либо бампер либо фару. Или я Вас не понял.
3. Про «второй момент» не понял, можете пояснить, кто получает выйгрышь?
И еще. Сравните два sql. Необходимо найти Масло до $30 и либо Mobil либо Castrol.
SELECT * FROM objects t INNER JOIN int_property t2 ON t.id = t2.object_id AND t2.prop_id = 101 /* это цена */ INNER JOIN string_property t3 ON t.id = t3.object_id AND t3.prop_id = 102 /* тип масла */ INNER JOIN string_property t4 ON t.id = t4.object_id AND t4.prop_id = 102 /* тип масла */ WHERE t2.value < 30 AND (t3.value = 'Castrol' OR t4.value = 'Mobile') ==== SELECT * FROM oil WHERE price < 30 AND (type = 'Castrol' OR type = 'Mobile')Что быстрее?
Что может быть «с переменным кол-вом свойств»? Например, добавление нового товара в каталог Интернет-магазина, где он добавляется/редактируется через панель. Думаю у вас что-то похожее.
Так вот, я бы сделал на каждый товар по таблице. А в админке запросы пользователя переводил на alter'ы (редко товар меняет свойство, соврее добавляет новые);
Так скрость возрастет, база станет более «понятной», упрастяться sql;
А если идти вашим подходом, то в конечном итоге так всю базу можно запихать в одну таблицу (id, var_name, var_value)
select * from blog inner join ( select from comment where blog.id = comment.blog_id order by comment.date_created desc limit 10 ) as comment on comment.blog_id = blog.id where blog.type = 3 order by blog.date_created desc limit 10Но задача «не живая», на практике за такое надо по пальцам бить и отдельные сущности выбират разными запросами
У некоторых нет доступа до консоли на хостинге.
Может стоило заранее запустить генерацию и уже представить результат?
А как править данную форму дизайнеру?
Т. к. у sqlite один файл на все таблицы, то при записи будет блокировка ВСЕЙ базы, и во время параллельных запросов на запись отставание sqlite будет очевидным. У MySQL блокировка может быть на уровне таблиц или строк.
Так что ваши тесты не отражают реальных вещей.
Из возможных улучшений.
— еще не плохо, при вращении, отменить выделение текста.
— возможность поставить фокус и управлять стреклами
Но и без этого пригодиться