LINUX.ORG.RU

Пыхотред

 


1

5

А чего это у нас, в нашем загончике, нет закрепленного пыхотреда?

Вот теперь есть(надеюсь, его закрепят).

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

В тред приглашаются все пыхобоги, пыходемоны, пыхофрилансеры, простые пыхари, и даже пыхоненавистники.

Обсудить есть много чего, начиная с различий версий, особенностей языка, CMS-ок, фреймворков, и заканчивая говнокодом.

<?php

Ответ на: комментарий от ritsufag

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

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

anonymous ()
Ответ на: комментарий от AndreyKl

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

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

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

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

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от cab

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от Deleted

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

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous ()
Ответ на: комментарий от AndreyKl

там где хорошо работает орм, никакого мудрого 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
Тут знать нечего, всё куль!

anonymous ()
Ответ на: комментарий от AndreyKl

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

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

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

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

    парадокс!

anonymous ()
Ответ на: комментарий от AndreyKl

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

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

anonymous ()
Ответ на: комментарий от AndreyKl

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от AndreyKl

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

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

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

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

Deleted ()
Ответ на: комментарий от anonymous

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

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

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

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

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

alienclaster ★★ ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от AndreyKl

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

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

cab ★★★★ ()

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

lovesan ()

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

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

ilja-ilja1990 ()

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

anonymous ()

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

vasya3 ()
Ответ на: комментарий от vasya3

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

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

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

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от anonymous

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

tz4678 ()
Ответ на: комментарий от anonymous

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

tz4678 ()

tz4678

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

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

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

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

deep-purple ★★★★★ ()
Последнее исправление: deep-purple (всего исправлений: 1)