Пыхотред

еще раз. многие запросы на орм не решить вообще.

пусть уж лучше пишут sql.

Алё, маппишь любой ответ на любой объект

Что значит любой? Объект имеет определенный интерфейс. Любой ответ ты им не обернешь. Разве что это будет «объект» как в жаваскрипте, т.е. тупо хештаблица. Так можно и без всякого орма захреначить.

Мне нужна сущность со связями, я беру и достаю её raw sql запросом. Какие проблемы?

Ну собственно там точно так же: делаешь бегин и делаешь коммит.

Вот, собственно, и моя претензия в недостаточной абстракции ORM-ов. тебе все равно приходится возиться с сущностями СУБД. А ORM, по идее, должен тебя от этого избавлять.

но ты ведь не пишешь на ассемблере, правда?

Заодно и no-such-file отвечу. Я, когда пишу на java, swift, kotlin, sql, bash, python, lisp и собственных DSL, не лезу в нижний уровень - регистры и т.д. В случае с ORM всегда надо держать в голове его сущности и сущности того, поверх чего он работает. И, если решение на ORM становится достаточно сложным, то переключаться на нижний уровень. А на сложной схеме переключаться приходится постоянно. Целесообразнее иметь дело с чем-то одним.

сущность

если это не сущность, на какой объект ты будешь это мапить?

А на сложной схеме переключаться приходится постоянно. Целесообразнее иметь дело с чем-то одним.

Этот аргумент я понимаю. Но обычно заменять на чистый sql себе дороже всё таки. Больно он многословный и трудноуправляемый (в смысле запросы приходится как то составлять динамически, а это ведь строки..). В целом я склоняюсь к использованию более лучшего dsl, если есть возможность. Елси нет - использую orm + sql.

гм, ну два подхода для решения проблемы
1) пиши sql , таких мест слава богу не большинство
2) как сказал no-such-file сущесвтвуют виды (views). Я не сторонних хранимок и логики на них, но в видах ничего криминального не вижу

я просто пишу sql если задача выходит за orm

Я вообще тут провожу агитацию против орма. Но если уж рукожопы выбрали орм, надо ему следовать, а не читить «вот тут мы sql пробросим, никто не заметит». Просто потому что рукожопы, выбравшие орм расписались заранее в неосиляторстве sql, и конечно ничего хорошего из их запросиков не выйдет.

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

2) если ты выбрал кушать хлеб, надо этому следовать, а то ишь, напридумывали, не только хлеб (да ещё и не столько хлеб!) едят! уроды прости хоспаде.

если ты выбрал ходить, то уж надо этому следовать, зачем ты используешь транспорт? рукожоп ты эдакий.

ORM.. Ну, да, сдаюсь, согласен. С ним, действительно, выглядит красиво у AndreyKl. Следующий раз попробую.

Берите что то вроде yii2 или laravel, кохана не поддерживается уже вроде. Правда я не знаю получитсья ли отцепить от них их орм.

Я бы взял фреймворк целиком. Поглядел бы доки пока есть время, попробовал тестовые примеры, выбрал. Хорошо прочитал доки.

Очень мило, что ормодебилы все хором заголосили «да, мы делаем sql». Прекрасная иллюстрация просасывающей абстракции.

да нету у них там никакой абстракции, а то что дебилы эт точно:

sql ... Больно он многословный и трудноуправляемый (в смысле запросы приходится как то составлять динамически, а это ведь строки..).

оказывается SQL многословный, а закат солнца вручную - нет, оказывается

что интересно, они никак не могут понять, что разговор не о том, что лучше и или удобнее, а о том, что на ORM вообще нельзя (или запретительно трудно) самых основных вещей сделать, но они каким-то странным образом с этими простыми и базовыми вещами не сталкивались.

там где хорошо работает орм, никакого мудрого sql не бывает.

Совершенно верно. Там обычно такое:

select foo_id, bar_id from foo
select * from bar where bar_id = 1
select * from bar where bar_id = 2
...
select * from bar where bar_id = 100500

где хорошо работает орм, никакого мудрого sql

ORM это уникальное дерьмо. ORM хорош для учебного хелловорлда, в котором по джойнам с каким-то условем «выбирают сущность из таблицы». при этом он не подходит для чего-то обыкновенного, типичного для среднего простого сайта или приложения.

таким образом:

• на синтеческих радикально простых задачах вроде скрипта из 30 он иногда работает, но там он неуместен
• а там где он мог бы быть уместен - он не работает вообще

  парадокс!

в твоих словах есть доля правды.

в смысле запросы приходится как то составлять динамически

Да, проблема формирования запроса реальна. Но причем тут ORM?

Мы говорим о том, что на нужно programmatically формировать текст запроса. Значит нам нужнен инструмент который бы помогал формировать нативный, в смысле вендорный SQL, и имел бы разумный интерфейс и эргономику.

• Но через api типа select().from().where().bezumie() невозможно написать даже простой SQL запрос, это очевидный факт.
• Во-вторых итоговый запрос в имеющихся решениях строится из совершенно другой абстрагированной модели запроса. Т.е. мы строим _нечто_, что потом должно отрендериться в целевой sql-язык. А нам нужно манипулировать не только реальным SQL, но причем вендор-специфичным.
• В-третьх мусор вроде HQL, DQL или как их там называют еще хуже и вообще эти проблемы не решает.
• В-четверых проблема программной манипуляции запросом особенно остра когда колонки калькулируемые, и сама структура резалт-сета динамическая. Но для ORM такое - показательный провал.

Т.е. ORM называнную проблему вообще никак не рашает, наоборот препятствует этому. Возмозможно даже какой-нибудь тектовый макро-препроцессор справился бы с ней лучше.

Кстати мне не известно никакого инструмента, который бы решал эту задачу.

Но через api типа select().from().where().bezumie() невозможно написать даже простой SQL запрос, это очевидный факт.

отнюдь. http://squeryl.org/ , http://slick.lightbend.com/docs/ , https://github.com/bitemyapp/esqueleto .

Из них я пробовал squeryl и по моему это работает весьма неплохо.

Кстати мне не известно никакого инструмента, который бы решал эту задачу.

HaskellDB говорят крут в смысле «не течёт», но у него реальные проблемы с производительностью.

Есть из интересного opaleye, но я его не смотрел внимательно, всё времени нет.

Есть ещё haxl, примеры у них очень любопытные, но я не разибрался.

Задача того же рода, что и генерация HTML. Когда-то диды ломали головы как же сделать параметризуемую страничку, загадка века. Склеивали принтами сначала, а потом устали и изобрели PHP! Следующий шаг - специализированные шаблонные языки либо расширение HTML кастомными тегами. Почему для SQL так не делают вопрос. Наверно потому что средние кодеры ненавидят SQL как таковой. Любой орм продается в первую очередь как средство избавление от SQL. Макаки готовы писать тонны метаинформации и выделывать кульбиты с цепочками методов лишь бы не ужасный страшный SQL.

если метаинформацию не описать в одном месте, то её приходится упоминать в каждом божьем запросе, что вдесятеро нуднее чем орм, со всеми его недостатками.

Как же в одном месте, если вы все по классам размазываете. 100 таблиц => 100 классов. А сколько там может быть связей задачка на дом из комбинаторики. Все это так или иначе нужно описывать. В запросе оно наиболее естественно и близко по контексту, хотя и возможно многословнее.

отнюдь. http://squeryl.org/ , http://slick.lightbend.com/docs/ , https://github.com/bitemyapp/esqueleto

Я начал смотреть slick, но ничего не понимаю, если честно. Правда что-то мне подсказывает, что этот подход развалится сразу же на вещах вроде каких-нить cte, laterаl join-ах, window functions, rollup-ах, вендорных кастингах, операторах и т.п. Хотя возможно я ошибаюсь.

И возможно оно не «помогает строить вендорный SQL», а делает опять что-то другое, хотя может быть я не понял просто.

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

единственная разница с орм вроде актив рекорд, что обвзязка уже написана, надо только метаинформацию добавить.

в целом, повторюсь, подход написания «настоящего» sql вместо activerecord я считаю разумным (естественно с оборачиванием в сервис), но у меня приоритеты такие

1) squeryl (или что то может из хаскеля, я ещё не глядел)
2) анорм
3) орм + sql

анорм - это на скале, там в основном голый sql.

хотя инога мне кажется что я бы поставил анорм на 1е место, из за сложности со сгенерированным кодом и изучением технологии.

Для более приземленных языков есть что? По идее для го должно быть что-то такое, потому что я не очень представляю как сделать орм в го.

Вообще, тут напрашивается строго внешний DSL. Попытки запилить это в рамках базового синтаксиса хоть даже в лиспе это провал. Для генерации html кстати edsl нигде не взлетели.

инструмента, который бы решал эту задачу
Почему для SQL так не делают вопрос.

были какие-то такие попытки. именно так было в какой-то древней библиотеке сделано в начале или середине 2000х. типа ты пишешь нормальный SQL (для либы это просто текст), но где хочешь используешь специальный синтаксис, запрос отправляетс в неизменном виде, заменяются/раскрываются только участки с «макросами». макросы были какие-то уже не помню, но именно под типичные sql-задачи, типа билдинг блока VALUES, IN, исключение условия из блока WHERE. как называлась не помню, русская какая-то под php. что удивительно удобная была даже.

Видел такие лисапеды и сам использую. Вот только массам это не нужно, им продали уже орм.

Я не обещал что это легко. Порог вхождения в эти штуки повыше чем в ActiveRecord.

Еsqeleto - клон squeryl , если я верно понял.

Могу тебе сказать что со сликом я не работал. Глядел на него внимательно, но до использования не дошло.

Вот тут есть плагин для postgres https://github.com/tminglei/slick-pg

они заявляют о поддержке window function, agreagte functions , композиции, в общем смотри список фич, по моему это похоже на вендор-специфичный sql.

что до squeryl-а, то как я помню автор не очень любил вендор-специфичные вещи и ориентирвался больше на стандарт. со всей вытекающей переносимостью... и конечно ограничениями. может быть можно было бы сделать плагинами как в слике, может уже и сделали что то.. я давно не глядел.

Но sql он позволял писать вполне, пусть и не вендор-специфичный.

Для более приземленных языков есть что? По идее для го должно быть что-то такое, потому что я не очень представляю как сделать орм в го.

не знаю, к сожалению, поэтому не подскажу. я уже даже за php и javascript-ом почти не слежу, хотя всё ещё зарабатываю на этом. надеюсь начать рабоать на хаскеле или идрисе в ближайший год.

Вообще, тут напрашивается строго внешний DSL.

Ну, я пробовал myBatis , для явы, там в xml запросы пишутся. в целом конечно удобнее чем писать sql в тексте программы. и генерировать получается (вроде как шаблоны). Впечатления хорошие остались, его бы я предпочёл activerecord'у точно.

Почему для SQL так не делают вопрос

Потому что все сосредоточились на мапперах чтобы переливать в ООП-объекты и обратно (тут маппер действительно освобождает от рутины, ценой чего другой вопрос), плюс на желании не писать SQL вообще в некоторых случаях, плюс на призрачной возможности менять СУБД.

Берите что то вроде yii2 или laravel

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

Phalcon еще куда ни шло. Всё ж на Си написан. Переводчики правда никуда не деваются, зато не так жалко вычислительные мощности.

Это ж речь про AstraLinux была. Там модифицированные Астрой спец-Apache, со спец-php, на спец-Postgres. Из того что в глаза бросается снаружи - Apache у них не может разговаривать от анонима в отличие от www. И в Postgres встроены мандатные метки. Особенностей php не заметил. Там чем меньше стороннего ПО, тем лучше.

А, если требования особые, тут вам конечно виднее, тем более если вы их глядели.

Попытки запилить это в рамках базового синтаксиса хоть даже в лиспе это провал.

Какие варианты рассматривал? В лисповых dsl можно ведь и синтаксис sql сохранить 1 в 1 и получить плюшки orm типа маппинга в родные структуры искаробки и ф-ции яп над ними использовать во все поля, параметризация запросов, составные, отложенные запросы, читаемый код, макросы итд итп.

Такой себе sql++.

Вообще, тут напрашивается строго внешний DSL.

Типичные orm - это в принципе и есть поптыка такого dsl на самом деле, только плохая. Потому что ооп.

при этом он не подходит для чего-то обыкновенного, типичного для среднего простого сайта или приложения

толсто, или может просто кривые руки мешают, пример выше с n+1 запросом в нормальных орм решается легко, а такая хрень с кучей запросов как раз выходит у тупых школьников.

Больно он многословный и трудноуправляемый (в смысле запросы приходится как то составлять динамически, а это ведь строки..).

Нет, на самом деле. Во-первых, большинство задач в хранимках. Плюс не шибко сложный самописный API для генерации всего, что нужно, типа запросов модификации, обновления текущеей записи, представления в самых распространенных форматах. В итоге, генерация SQL в коде не такая уж и частая задача, которую облегчает хорошая SQL IDE. И через такую IDE легче рулить сущностями БД, чем через ORM.

Товарищи пыхеры! Может мне кто-нибудь объяснить, как нормально деплоить вордпресс сайт? Допустим я его разрабатываю на лохохосте, или на дев окружении, а потом как на прод складывать правильно? Или там, тем более, на какой-нибудь SaaS типа wordpress.com ? Можно конечно тупо делать дамп базы, но в этом случае почему-то слетает часть картинок. А как правильно?

Собственно, вопрос.

Ищу форум, чтобы войти в вордпресс и yii2, и за короткое время зарабатывать большие деньги. В вордпресс, как я понял, зарплаты от 200 000 руб.

В вордпресс только за еду берут

Если эта еда стоит 200 000 руб., то why not?

Спец. для анонимусов, которые ORM не осилили - вы совсем не с той стороны подходите! В ORM рулит не запрос, а сущность. А это позволяет делать крутые и очень удобные вещи. Например, в новом Symfony, делаешь Entity, обмазываешь её валидаторами и прочими аннотациями, тип объекта суёшь в форму, для чего-то более сложного (взаимодействии всяких там, запросов) делаешь Repository - всё. Наверное, на буквах выглядит страшно, но только сами попробуйте - красота, минималистичность, логичность что прямо офигеть. Сам на своём последнем проекте удивился, как изящно, сухо получилось. С запросами, не изобретая собственного ORM, так чисто просто не получится. А для сложных запросов (например, статистики там) никто нативного SQL и не запрещал. Засуньте только его в подходящий класс - маппер и всё.

Очень давно не ваял ничего на пыхе. Профи, подскажите, какой бекенд-сервер нынче лучший для php7 (nginx + ?). Apache, php-fpm, еще что-то?

Практически каждый программист, хотя бы раз в жизни, что-то да писал на пыхе.

Теоретически. Максимум - читал.

nginx + php-fpm

Кто-то знает нормальную реализацию многопоточности на пыхе?
Если phthreads - тогдв хоть дочтупно и с примерами.
У меня вся логика, все функции и библиотеки реализованы на пхп. (Т.е., изучать питон, чтобы туда переписывайт не айс как бэ).
Есть (просто пример), 50 аккаунтов, по каждому из них разные параметры в бд. Есть скрипт, который запускается по крону. Таймаут у него, как и у всего остального 90 секунд и менять не хочу. Функция принимает параметром id аккаунта и обрабатывает на основе данных из БД, скрипт выполняет функцию для каждого аккаунта по очереди. Всё проходит быстро. Но на финальном этапе функция обращается к неторопливому api внешнего сервака, который жуёт и спустя время выплёвывает ответ. Всё бы хорошо, но в 1 поток наступает таймаут скрипта, а конкретно из-за этой логики таймаут вообще для всего (с чем и пользователи взаимодействуют), менять нерезонно.
Нужна максимально простая реализация конструкции, которая запустит функцию с каждым акком параллельно 50 раз. Время респонза буржуйского апи не меняется, сервак с огромным избытком держит. Даже необязателен результат по каждому таску, успех каждый инстанс функции запишет в бд.
Посоветуйте самый доступный мультитридинг, который просто запустит одну функцию с 50 параметрами.

Многопоточность в пыхе — полное говно.

Бери многопроцессность. Запускай в фоне, когда надо что-то перелопатить.

Если нужно узнать как оно отработало, вижу такие варианты:

1) Передав процессу уникальный параметр, пусть он создаёт файл с таким именем и туда гадит результатами.

2) Бери шаред мемори. Причём ВАЖНО!!! пыховый шмем НЕ ТОТ САМЫЙ ЧТО НАСТОЯЩИЙ (нет, вру, есть там и настоящий, но он кривой). Короче для общения всех пыховых процессов, в том числе и тех что под попачем или цги или фпм — подходит этот пыховый «игрушечный» шмем и семафоры. Это чутка сложнее файлов, зато все данные висят в памяти, ответ быстр и блокировка имеется.

напомните, как там у php с поддержкой юникода? простые функции все умеют или нужно специальные функции дёргать? :)

Многопоточность в пыхе — полное говно.

можно подробнее? можно даже со ссылками?

(давно пыхом не пользовался, надо орудий насобирать)

С юникодом всё ещё дёргать mb_*

Треды опять «игрушечные», ещё и конпелять надо чтобы заработало. https://www.sitepoint.com/parallel-programming-pthreads-php-fundamentals/

на голом sql писать - означает большую гибкость, использование orm - экономия твоей бесмысленной жизни. да и с конкатенацией строк ебаться не надо при построении запросов. в java-мире вообще любят dao-паттерн, но это все равно sql вручную писать. php... в принципе можно обойтись, тем более код можно нагенерировать скриптами. про неосиляторство неверное рассуждение. что там осиливать? - это язык для домохозяек. иное дело что чтобы пользоваться orm все равно нужно знать основы sql, ну про типы данных, первичные, внешние ключи, индексы, джойны и т.д. нужно знать. неосилятор sql не сможет в orm.

в принципе, да: извлечь запись из базы (SELECT), создать объект из нее, чтобы потом его удалить (DELETE) - со стороны выглядит идиотизмом. а вообще из базы лучше ничего не удалять, вместо этого завести поле removed и при удалении помечать его как true.

tz4678

Мы же байтики заменяем

$s = 'рстуфхцчшщъыьэюя';
for ($i = 1; $i < strlen($s); $i += 2) {
    echo hexdec(bin2hex($s{$i})) . PHP_EOL;
}

Эти коды (второй байт UTF-8 русской локали) попадают в Extended ASCII. И это еще простой пример. В более чем двухбайтных символах можно напороться на одинаковые последовательности бит (и байт) и в итоге заменить не то и не на то. Думай.

И поубавь-ка пыл с матершинкой.