Gaius Cassius
люди просто modx не знают, но знают sql)
ну, вообще) впервые видим систему)
Gaius Cassius
нужно больше циклов
Sergey_K
Ну да, ну да :)
Павел
Я еще раз спрошу - как написать в ПДО запрос UPDATE JOIN?
$q = $modx->newQuery('modResource'); $q->command('update'); $q->innerJoin('ShopmodxProduct', "Product"); $q->set(array( "price" => "Product.sm_price", )); $s = $q->prepare(); print $q->toSQL();
Sergey_K
А потом с помпой артурчик презентует прямой запрос к базе
Павел
Прям вообще ничего сложного
Павел
И это сейв код
Nikolay
Я еще раз спрошу - как написать в ПДО запрос UPDATE JOIN?
только хотел скинуть - $q->command('update');
Павел
Сидеть 2343534645645645 секунд залипать на то, что код безопасен и быстр Не вижу в этом смысла
Nikolay
но сам не пользуюсь, поэтому долго искал))
Nikolay
не ну для чего-то сложного, я лучше на sql напишу
Gaius Cassius
Сидеть 2343534645645645 секунд залипать на то, что код безопасен и быстр Не вижу в этом смысла
видимо не стоят такие задачи отклик должен быть быстрым магазину - пофиг, а в других системах - и пара доль секунд решает
Sergey_K
Изначально
Павел
Херпоймичо написано, если честно. Я про яитабельность. Там апдейт двух таблиц?
Вот тебе пример с Docrine qb = $this->getEntityManager()->createQueryBuilder(); $qb ->update('MyBundle:Entity1', 'e1') ->set('e1.visibile', '1') ->where('e1.Entity2 = :id') ->setParameter("id", 123) ; это тоже не читабельно?
Sergey_K
Это +- да, норм.
Sergey_K
Но как там будет апдейт джойн хз
Sergey_K
Хотя бы по двум таблицами
Nikolay
блин ну это уже такие вопросы, типа что лучше orm или sql? как бы история показала, что orm не просто так придумали
Павел
видимо не стоят такие задачи отклик должен быть быстрым магазину - пофиг, а в других системах - и пара доль секунд решает
Между безопасностью и скоростью я выберу второе. Критические участки можно закрыть raw кодом, но писать его везде при живом SQL - жесть, за которую в компаниях бьют по рукам
Sergey_K
Я не уверен. что пдо параметризует НОРМАЛЬНО запросы. Хотя хз.
Gaius Cassius
Я не уверен. что пдо параметризует НОРМАЛЬНО запросы. Хотя хз.
не, с параметрами там гуд и проверочки и подстановочки, все отлично
Sergey_K
Наверное, я помню, что мы давно спорили и там "заливалось" все одним текстом.
Nikolay
вот ещё что есть https://modzone.ru/blog/2018/02/07/eloquent-and-modx/
Павел
Павел
Погуглите про Entity Code First
Sergey_K
Ну наверное. Я, может, за хардкор, но ощущение, что все системы этого класса сделаны с сильным компромиссом. Для того, чтобы человек не парился лишними знаниями и при этом мог.
Павел
сырой sql даже в лютейшем интерпрайзе стараются не использовать
Nikolay
писать классы для orm впадлу
ну хз, надо пробовать)
Sergey_K
сырой sql даже в лютейшем интерпрайзе стараются не использовать
В лютейшем интерпрайзе все намного проще и логичнее
Sergey_K
Там все построено на View и Store procedures
Павел
В лютейшем интерпрайзе все намного проще и логичнее
видел хоть один проект который работает 20+ лет ?
Nikolay
sql это можно сказать низкоуровневый язык, а orm, высокоуровневый. Хоть это не язык, но что-то в этом роде. В любом случае по скорости разработки он проиграет
Nikolay
sql в смысле
Nikolay
а по скорости работы как и любой низкоуровневый выиграет
Павел
Давайте начнём огонь трением добывать
Sergey_K
видел хоть один проект который работает 20+ лет ?
Я, в общем, руководил проектом в т.ч. и по доработкам систем. Там были business critical системы. Телеком, юзеров достаточно.
Павел
А хули нет
Sergey_K
Да и везде одно и то же, в общем
Sergey_K
Что в средних, что в больших.
Павел
Программисты придумали ORM - люди его не юзают. Почему ? Потому им по Кайфу писать raw код
Sergey_K
OeBS сколько лет, я не знаю?
Sergey_K
Я хз, но вопрос в том, что реализация стандартными методами SQL проще и быстрее
Sergey_K
НО надо знать sql :)
Павел
НО надо знать sql :)
Никто и не говорит что не должен знать
Sergey_K
Затем, что люди ленивые. Как минимум.
Nikolay
не ну обновить данные, выборки сделать я на sql могу, но не хочу, т.к. мне удобнее стандартными средствами
Nikolay
а главное думать меньше надо
Nikolay
никто почему-то не учитывает ресурсы своих мозгов
Павел
Затем, что люди ленивые. Как минимум.
а, в этом дело. дело ж не в скорости разработки, секьюрности и нативной поддержкой многих паттернов дело в ленивости, точно
Nikolay
зато парятся насчёт ресурсов железки
Nikolay
если бы можно было сделать что-то чтобы не думать, я бы это сделал!)
Nikolay
в среднем моя башка работает процентов на 70-100 даже при том, что я стараюсь облегчить себе по максимуму работу. Думаю у остальных в этом районе. Вот где надо оптимизировать)) железки для того и придумали
Sergey_K
Секьюрность это, видимо, пароль админа бд в файле
Sergey_K
SQL у тебя не копипастится чтоль? :)
Sergey_K
Ну ок
Gaius Cassius
Sergey_K
Это домашняя заготовка, самый убойный аргумент :)
Sergey_K
Про секьюрность, конечно, эпик фейл.
Sergey_K
Если я украду пароль из файла модх, я дропну базу. Если делать все то же самое на вьюхах и процедурах, то украв пароль, я ничего неразрешенного украть не смогу. Просто потому, что данный юзер на уровне БД не имеет никаких лишних полномочий.
Sergey_K
Не говоря о том, что инжекция во вьюху невозможна
Sergey_K
Короче, старая песня, не буду повторяться.
Nikolay
осталось только написать такую крутую и безопасную цмс)
Nikolay
чтобы там по функционалу хотя бы аналогично modx было
Nikolay
а не тупо заготовка для создания лендингов
Nikolay
хз, я не в курсе как там и что
Sergey_K
У такой цмс все будет сильно круче, но она не попрет. Т.к. входной порог высокий. К сожалению.
Nikolay
как я понимаю под круче подразумевается безопасность и скорость работы, а не скорость разработки)
Nikolay
последняя будет хромать
Sergey_K
Скорость разработки?
Gaius Cassius
не забывайте, что система все же делается для конечного пользователя
Sergey_K
Ну посмотри кол-во джойнов для вывода данных в форме заказов