Pavel
Разве все имена, начинающиеся на "T" — это точное совпадение?
Pavel
$users = DB::table('users')
->where('name', 'Махмуд')
->get();
Luka
просто у меян в таблице есть такие размеры
S (42-44)
и
S
Luka
Надо чтобы нашло только S
Luka
LIKE найдет только S ?
Pavel
Так, у тебя в запросе была таблица с пользователями и фильтрация по именам
Pavel
какие размеры вообще?
Luka
Да все вопрос решен
Luka
нашло только S
Luka
я просто про функцию)
Luka
$size_db = DB::table('oc_option_value_description')
->where('name', 'like', 'S')
->get();
Luka
вот запрос
Maksim (Ellrion)
я просто про функцию)
->where('name', 'S') или ->where('name', '=', 'S')
Maksim (Ellrion)
но никак не лайк
Aleksey Y.
real time кто-то делал?
Aleksey Y.
типа redis + socket.io + echo
Aleksey Y.
комментарии или чатик
Джамиль
invariance
как по мне
invariance
ДЕЛАТЬ СОКЕТЫ НА ПХП ЕБАНЫЙ ПИЗДЕЦ
Maksim (Ellrion)
ДЕЛАТЬ СОКЕТЫ НА ПХП ЕБАНЫЙ ПИЗДЕЦ
и причем тут это? не хочишь не делай. в стеке который чувак назвал там нет сокетов на php
invariance
мне придется свой сервак под сокеты пилить(
Maksim (Ellrion)
да и кстати сокеты на php шикарно пашут. еще и быстрее ноды)
Aleksey Y.
я к чему, у меня срок до четверга нахерачить риалтайм комменты, но с node.js и socket.io не работал
invariance
да и кстати сокеты на php шикарно пашут. еще и быстрее ноды)
да, потрясающе, просто великолепно, блять
Aleksey Y.
есть годные доки на тему?
Aleksey Y.
мне без pusher.com главное
Aleksey Y.
пользователей может быть больше 100, а согласовать оплату пакета я не успею
invariance
назови хоть одну причину почему нет?
нипочему, это мое субъективное мнение, что заебали делать из стиральной машины подводную лодку или танк или еще хуй знает что
invariance
мне недавно сказали про то, что можно пхп транспилить в джаву. Вот это где то на том же уровне
Maksim (Ellrion)
нипочему, это мое субъективное мнение, что заебали делать из стиральной машины подводную лодку или танк или еще хуй знает что
ага заебали, сделали из языка шаблонизатора какой то язык общего назначения. вот козлы то
invariance
"А давайте захуячим многопоточность, а давайте захуячим сокет сервер, на языке, который вообще не для этого предназначался"
Aleksey Y.
я вас отвлеку от срача
invariance
да эт не срач, я просто выливаю)
Aleksey Y.
подкиньте линк на ларакаст)
invariance
сорян
invariance
подкиньте линк на ларакаст)
https://laracasts.com/series/lets-build-a-forum-with-laravel в этой серии по-моему было
Aleksey Y.
спасиб, ща гляну
Maksim (Ellrion)
подкиньте линк на ларакаст)
https://laracasts.com/series/real-time-laravel-with-socket-io
invariance
да, еще этот
Antonio
Есть форма, в которой вводятся данные для модели и списка связанных с ней моделей( например: данные заказа + перечень товаров). Лучше передавать все одним запросом, а на месте создавать разные модели или по кускам: сначала отправить/сохранить/получить ids связанных данных( товаров), а затем уже отправлять запрос на сохранение всего заказа вместе с массивом связанных ids?
Эмин
На мой взгляд лучше 1 запросом
Эмин
легче дебажить
Эмин
и описывать логику
Эмин
тем более должна быть валидация
Эмин
а ее проще делать кучей
Эмин
+ транзакции проще делать когда все кучей
Antonio
Ну не в этом дело, вообще.
Эмин
тогда я совершенно не понял вашего вопроса
Antonio
Валидация как раз порознь приятнее, поскольку объекты могут создаваться и отдельно. Для всего этого предполагается использовать методы в api
Эмин
если во второй пачке данных будет ошибка - что вы будете делать с первой пачкой данных?
Эмин
будет ли она считаться валидной?
Antonio
Да будет считаться.
Antonio
И ещё, там могут быть не только товары создаваемые клиентом, но и уже имеющиеся в базе
fLipE
всем привет
кто-нибудь занимался переносом кода со старых велосипедных фреймворков на laravel?
Эмин
И ещё, там могут быть не только товары создаваемые клиентом, но и уже имеющиеся в базе
Я бы не разбивал на несколько запросов.
Эмин
особенно если у вас нагрузка хорошая
Antonio
Есть форма, в которой вводятся данные для модели и списка связанных с ней моделей( например: данные заказа + перечень товаров). Лучше передавать все одним запросом, а на месте создавать разные модели или по кускам: сначала отправить/сохранить/получить ids связанных данных( товаров), а затем уже отправлять запрос на сохранение всего заказа вместе с массивом связанных ids?
@ellrion @foIIeah @ontoho а можно ваши мнения узнать? ( Сорри если отвлёк)
invariance
Есть форма, в которой вводятся данные для модели и списка связанных с ней моделей( например: данные заказа + перечень товаров). Лучше передавать все одним запросом, а на месте создавать разные модели или по кускам: сначала отправить/сохранить/получить ids связанных данных( товаров), а затем уже отправлять запрос на сохранение всего заказа вместе с массивом связанных ids?
разницы нет особо) Зависит от вкуса скорее
invariance
как предпочитаешь сам
invariance
я б в один запрос фигачил
invariance
просто при этом максимально отслеживал бы все непредвиденные кейсы в релейшенах
Эмин
не вижу смысла сервер поднимать два раза если можно за 1 раз все решить
Anton
@ellrion @foIIeah @ontoho а можно ваши мнения узнать? ( Сорри если отвлёк)
Я бы тоже за один передавал - у тебя тогда путешествий от клиента до сервера меньше - экономия
Anton
чем меньше раундтрипов - тем круче
Anton
на мой взгляд
Antonio
Я бы тоже за один передавал - у тебя тогда путешествий от клиента до сервера меньше - экономия
Вот именно эта экономия с одной стороны и разделение логики с другой. Поэтому и возник вопрос из разряда бэстпрактис
Anton
Кто тебе мешает логику на сервере разделить...
Anton
можно даже сделать контроллер, который другие котроллеры вызввает
Anton
да хоть локальные запросы к endpoint делай, но со своего уже сервера
Anton
то есть контроллер что примет все данные и потом по очереди другие ендпоинты зовет
Anton
вот тебе и разделение и экономия 🙂
Antonio
то есть контроллер что примет все данные и потом по очереди другие ендпоинты зовет
Каким образом это делать? На пальцах можно пример?