Не, если делать первым способом то у вас таблица и модель Categories, (и может быть таблица для дерева и модель к ней CategoryClosure либо вы в категории делаете поле `path` или например `url` и в нем держите путь через слеш). И вы сначала отдельным скриптом пробегаетесь по всем вашим книгам и заполняете таблицу categories по вложенности, а потом с ней работаете.
Биндинги это не кнопка, это есть такой мидлвар, который подкидывает на фход действия модельку, запросив из базы по тому, что является частью роута (то есть по стандарту на вход функции приходит то, что есть в роуте, а этот биндинг использует это, чтоб в базе поискать и дать тебе сразу модель), и его еще настраивать надо (т.к. у тебя в роуте идет slug, а он по-дефолту ищет по id). Там внутрянка, вам тогда лучше сделать вторым способом.
Мил человек, а откуда в сокете сессия? Может я чего не понимаю, но сокет - это фоновое приложение, к нему подключаются клиенты из браузера, и что отправишь - то и придет, сессия там функционирует в режиме "чтобы она появилась - её нужно передать".
Николай Алексеев, тогда как я злюсь от того, что нормой для русского мира является ржать над чужой болью. И его это еще больше веселит и также лицемерно продолжает оправдываясь цеплять меня снова, зная что меня это злит. Ну и как тут не делать срач? Он подходит ко всему с позиции бога, я пытаюсь ему в это ткнуть, но "русский мир" в этой больной голове не дает ему осознать, что ты делаешь хуже, не для меня, для всех. Я бы хотел "просто забить" но это поведение ужасающе притягивает забитое палками население быть такими же как он, потому что только глупцы в обществе где кругом "я круче" занимаются помощью остальным. Не глупцы просто побеждают и всячески это демонстрируют. То есть меня злит не он, он человек, один всего из миллионов, меня злит, что таким как он не дают по морде. Дарвинизм работает. Пока на улице не появляются танки.
Я бы сказал, что "люди сами понимают, кого и зачем слушать", но судя по последней обстановке в мире - ничего они не понимают и всегда предпочитали и предпочитают то, что работает. И нагибательство работает лучше, чем самоотдача. Лучше для всего, кроме спокойной жизни.
В конечном итоге, чтобы это игнорировать придется воспитывая детей рассказывать им про то, что "зло иногда допустимо", про "ложь во спасение" и в весь этот ящик пандоры, делая детей похожих на него, которые душат и громко смеются над слабыми. Рак общества начинается с мысли, что "вокруг все делают всё неправильно". А вот обратная сторона начинается с мысли "может они что-то видели, что я не знаю?"
Не важно аргументируешь ты ответ, ссылаешься ли ты на источники, в конечном итоге количество боли, которое отхавает тот, кто воспользуется твоим советом, будет зависеть от того, сможешь ли ты его выручить, когда у него будут трудности. Боги не выручают. Боги говорят что все вокруг глупые, "я тебе уже ответил", а при случае говорят что "ты даже элементарного понять не можешь". Тогда как моя позиция - если у человека не получилось - выйди с ним на связь и помоги исправить, раз взял советовать.
я правда не совсем понимаю как хешем группировать похожие, для меня хеш это типа md5 или что-то такое, и там группировка не получится, он тупо всегда уникален. Это как в книге алфавитный указатель буквы А назвать 42, а потом надеятся что Б будет 43... я думаю будет 1337.
С другой стороны, хеш он постоянен по длине. И это жирный плюс если его таки придется сохранить куда-то. Ну и реализации хеширования как правило работают быстренько, хотя разбитие по буквам substr() тоже неплохо. Поясните подробнее? Интересно знать ваше мнение.
Но функция типа `getIndex(values)` это вот да, надо, и как работать с тем, что завтра понадобится хеш вдруг поменять... в кейсе "4 буквы из каждого поля слепить через точку" - для тех, что новые, может быть пять букв, но первые 4 все равно ведут куда нужно, а новые - в другое место...
По мне так результат функций, выдающих имя "файла" индекса по значению чем больше похож на оригинальные данные тем, меньше нужно переписывать, если индекс в будущем надо достроить, тогда как если там рандом рандомыч, то малейшее изменение логики индексирования приведет к тому, что всё надо переиндексировать с начала.
Впрочем, допустим ElasticSearch вообще не парится. Хожешь переиндексировать - создавай новый, или дописывай в старый.
Ещё есть метод "надо индекс поменять - используй обе функции чтобы получить два имени и проверь в обоих", это ухудшает индекс (добавляя пару машинных операций на проверку двух мест вместо одного), но позволяет избежать "переиндексации миллиарда уже сейчас", так что по хорошему функция getIndex() сразу должна возвращать список мест, а не одно (а сам паттерн Хеш-таблица так вообще на этом строится, что возвращает элемент-цепочку с возможностью взять следующий если в первом нет ничего), в расчете что завтра каждое значение может вести в два места.
vilinyh, да, только getallheaders() встроенная функция. И она берет заголовки, которые сейчас ещё в реквесте, которые мог уже распарсить и схавать какой-то фреймворк.
Максим Федоров, ну они крутые да, умные очень. Они как бы это позволяют вместо того чтобы сразу в базу вписывать нагрузку это по времени тонким слоем размазать, собирая пачки не по задаче, а по времени например. В принципе даже это можно сделать чуть более централизованно, чем в каждом классе. Правда придется поставить RxPHP, и тогда для каждой модельки сделать пайп и туда складывать по принципу "each 5 seconds flush", и в конце скрипта сделать subscribe(). ибо, как мне кажется, по числу эвентов это странно заливать, а если под задачу - то это тот же самый flush() всего что накопилось, обычная вроде асинхронка.
Разве что их идея в том, чтобы накопить пачку событий, слить их в фоновую задачу и там применить залпом кучу, уменьшая время скриптов выполняющих саму логику и устранив соединение с БД в каждом скрипте. Получится фоновый сохраняльщик в БД, который ещё и в десяток БД сразу это может делать по принципу как binlog в бд.
Максим Федоров, Так да, просто есть в пыхе одна срань, которую разрабы по моей одинокой просьбе не будут менять. Она называется суперкласс. Когда ты можешь сделать класс-агрегат, который позволяет менять свойства того, класса, который считается дочерним для него. Условно на пхп это выглядело бы как "два класса в одном файле", но это противоречит psr-4 договоренностям.
То есть класс, который может менять защищенные свойства другого класса без сеттеров, а по дефолту эти свойства помечены в public readonly. А так каждый раз пишем сервис, который меняет свойства, чтобы в нем использовать эти самые сеттеры, т.к. иначе пришлось бы внутри класса писать методы бизнеслогики, что сделало бы из структуры - AR модель. Но классы как я уже сказал отличаются по назначению. В структурах нечего делать зависимостям на другие сервисы, тогда как в сервисах нечего делать полям (если это не режим работы или конфиг). В пыхе можно это обойти, что я часто использую, но очень осторожно. Просто делаю bindTo для самовызывающегося колбэка, который работает от имени дочернего класса и меняет там свойства. Шторм конечно светится, но я глушу php-doc-ами.
По мне это удобнее чем разбираться в EventDriven CQRS, и агрегатах.
Так и получаются сидят изобретают классы агрегаты, которые спамят события, которые потом накатываются, чтобы обеспечить порядок изменений... блин, я просто обернул себе для лары методы save()/update() и другие касаемые записи в менеджер, который контроллирует их порядок (как вызывал так и будет сделано) и подставляет в код запросов вместо объектов - их айдишники, а если объекта еще нет - валится в ошибку мол "сначала сохрани потом используй". Решилась проблема откатов изменений, т.к. есть доктриновский flush(), и решилась проблема когда "айдишника ещё нет, а уже пытаемся связать модели" - они вяжутся через сам обьект. Я не вижу больше проблем в БД ради которых надо писать калькуляцию изменений и новый подход. Этого действительно хватает, чтобы из кода исчезли beginTransaction() + commit(), и при этом можно было писать хочешь RAW запросы, хочешь Eloquent-Builder, хочешь Query-Builder, и использовать там объекты. Реально с БД после этого проблемы исчезли. Все проблемы.
На эту мысль меня навело то, что попытка поговорить с разработчиками на яваскрипте про ОРМ вызывает конфуз мозга у них - у них никогда не было наших проблем. Потому что их работа с базой асинхронная через промисы. Это всё что было нужно и обертка это сделала.
Максим Федоров, окрамиус и другие "оиусы" значит недостаточно хороший выпустил пакет, позволяющий его применять не так как задумывалось. воистину он создавал по теории, которая должна была решать единственную проблему - откат изменений и рассчет разницы перед записью, а написал такой дредноут что до сих пор матюкаются. при этом чтобы решать вышеуказанные проблемы, которые он решил, ему пришлось создать четыре новых. DQL который надо учить, писать код в комментах и приучать всех к аннотациям, заставлять вести метадату или выгружать её из бд, писать миграции на совершенно неочевидном синтаксисе, или придумывать генераторы кода, который должны бы работать но из теорий баз данных умеют только в четверть полезного. И то что его подняла толпа на руки - это как окрестить комедию американскую лучшим фильмом на земле потому что многим она понравилась. Ну людям нравится либо то что понимать не надо, либо то что понять невозможно. Мои библиотеки которые я пишу со взглядом на то, как это будут использовать и коллеги на работе читают их и говорят "как же просто и понятно" до сих пор никому не в дупу не впились. Мир сломался. Не сам конечно, как и СССР не сам развалился. Но кончится большим педуловом. Уже давно стало понятно.
Максим Федоров, точно это не сеттер, о чем я сказал да, я имел в виду что без сеттеров дело может быть труба. одно поле менять тем более делать метод снаружи класса просто его меняющий это так не надо делать. но отказываться от сеттеров совсем это только лишний повод думать, как назвать то что было раньше сеттерами. тут как и со всем - надо знать где. включить некий режим или подсунуть сервис-посредник сеттером разгрузив конструктор - там одно свойство меняется и это сеттер. но можно соорудить теорию почему это не сеттер, но выглядит как сеттер.
Вставлю своих пять, хотя и не просили.
Сеттер в сервисе - плохо. Сеттер в value-object - бывает удобно. Ещё сеттер бывает удобен в качестве какой-то тонкой настройки сервиса, а ля "включить режим такой-то". Да можно не писать там слово set() и написать changeMode() что будет лучше безусловно, но под капотом это как сеттер будет.
Писать
$order = new Order;
$order->changeProductCollectionAndCalculateTotalPrice(ProductDTO $dto) {}
может быть удобно, но таких методов понадобится столько сколько задач, и не получится один использовать и там и там, точнее - не всегда получится.
Горячий пример прям регистрация ИЛИ добавление юзера через приглашение. Вроде и там и там юзера добавить, и там и там проверить, и там и там сделать что-то ещё, но отличаются обычно один два поля и кусочек логики. Поэтому методы будут одинаковые, и исключить повторяемость в них можно только сделав методы поменьше, которые и там и там применяются.
Сеттеры и мелкие методы позволяют уменьшить повторяемость, но при этом увеличить вероятность неожиданного поведения.
Плохо и то и другое по отдельности. Нужна середина, а когда середина становится слишком большой - пишется второй класс.
Сеттеры даже в доктриновских энтитях есть и ничего, хвалят как-то умудряются.
Надо просто понимать, что пока логика небольшая можно сеттерами тащить, но правильно всегда иметь класс-сервис/класс-менеджер/класс-агрегат, который эти самые сеттеры потом применяет снаружи вовнутрь в нужном порядке, позволяя туда подключить другие с нужным функционалом.
Кстати из этого же опыта ругаются на AR-модели, хотя это не тема топика. Потому что они "сами себя сохраняют". Не позволяя сделать ни отложенную запись, ни очередность указать, и потом изменения откатывать надо если вдруг чего. То есть плоха не идея сеттера, а идея "супер-обьекта", который что-то делает над собой тысячу способами. Которая решается разбитием классов в голове на два типа - исполняющие и хранящие. Структуры и Сервисы. Валуе-обжекты и Менеджеры.
Сервис делающий работу над обьектом (структурой с голыми свойствами+сеттерами) всегда лучше, но писать дольше. Так что сначала пишут на AR, потом оборачивают. Ну нормально получается обычно.
К чьему-то счастью, а к чьему-то сожалению, иллюзия того, что вы как человек способны вести бухгалтерию в рамках закона, изучая сотни журналов и талмуды бухгалтерских книг с целью помнить номера проводок и "правила ведения" документов, защищать свою честь в судах на уровне дорогих адвокатов (уже подписываются за оплату просрочки, где это видано - зарабатывать на том, что кто-то работает медленнее чем обещал, когда пол-планеты не работает вообще!), иметь полторы тысячи связей как люди, которые не занимаются трудом, а разьезжают на встречи на дорогих машинах и самолетах, попытка сражаться с крупными бизнесами доказывая им, что 1 человек может столько, сколько и 150 - эта иллюзия исчезает. Возникает тот неловкий момент, который мне в детстве родители говорили. "А кто будет работать если все будут начальниками?" - Я тогда сказал - "идиоты пусть работают", мне было 17 лет. Сегодня я вижу, что идиоты здесь те кто работают, и это я, и сотни тысяч других. А не идиоты никогда не работали и не будут. А теперь этих идиотов еще и нанимают, чтобы топить в различные государственные национализмы под крики, что это проклятый коммунизм на это способен, а мы не такие и тут же, ТУТ ЖЕ - угрожают всем за "неверные" мысли. И становится совершенно понятно, что "неверные" мысли всегда связаны с тем, чтобы текущей олигархии, которая плевать на всех хотела, выставлять требования. За это садят, убивают, расстреливают. Какой бизнес, когда игра идет между вооружен-невооружен?
Не всегда правда получается как нужно, когда у разраба проекта есть повторы или элементы без классов, но это В ЛЮБОМ случае дает экономию по памяти и процессору. Библиотеки парсят весь документ и потом по нем ходят. Я пока не видел человека, который сделал бы парсер на генераторах, который работает с последовательностями, удерживая в памяти лишь один элемент и возможно - его родитель.
Попытка Symfony\DomCrawler с вложенными колбеками - попытка хорошая. Но под капотом DomXPath который валится на большинстве тех же ошибок, что и парсинг самим XPath.
Ичи Ня, вполне возможно, но как мы неделю назад рассуждали - её не сделаешь. Никак. Если это фронтенд - то он при определенных условиях все равно с бекенда запрашивает данные - он может их сразу внизу страницы класть из исходника в каком-то json, или запрашивать по апи, в этом случае парсить надо апи, а не верстку. Чтобы сделать лютую защиту от парсинга нужно увлечься теорией криптографии и написать псевдо-рукопожатие, чтобы это сделать, человек должен быть уровня "могу накодить свой вайлдберрис", а таких на работу не берут, они опасны для бизнеса тем, что могут стать конкурентами.
Так что самый такой доступный для обывателя способ защиты это число запросов в секунду с капчей. Если так не сделано - защиты нет.
Тильды использую потому, что шанс, что тильда в коде минимален. Но если это так, то можно сделать дважды preq_quote. На моей практике ни разу. А вот слеши - постоянно. Поэтому экранирую тильдами, а квочу - слешами.
Биндинги это не кнопка, это есть такой мидлвар, который подкидывает на фход действия модельку, запросив из базы по тому, что является частью роута (то есть по стандарту на вход функции приходит то, что есть в роуте, а этот биндинг использует это, чтоб в базе поискать и дать тебе сразу модель), и его еще настраивать надо (т.к. у тебя в роуте идет slug, а он по-дефолту ищет по id). Там внутрянка, вам тогда лучше сделать вторым способом.