Добрый день. Подскажите, у меня в базе есть поле с уникаольным значением. Я вношу в базу по одной записи. Если уже такая запись имеется, мне вылетает ошибки SQL. Как правильно в ларе делать проверку? перед записью производить поиск в базе и если значение найдено, то выдавать сообщение, еси нет то заносить? или есть более простой вариант?

Вообще ловить эксепшн записи в базу.

А что за записи? Почему уникальное значение вдруг не уникальное?

Ну человек заполняет базу Тэгами, если такой тэг уже есть. он не должен записаться, поэтому надо чтобы записи не было и вылетело сообщение return back()->with('message','Ошибка! Данный тэг уже есть в базе');

ну да, или exception ловить. Потому что с insert ignore есть забавная штука - если есть autoincrement поле, то оно будет увеличиваться, даже если запись не вставилась, а отсеялясь по ignore

firstOrCreate/ firstOrNew как вариант

Это же select

Можно рассматривать его как insert с предварительной проверкой на существование записи

В доке он в разделе "Other Creation Methods"

Как можно firstOrNew рассматривать как insert, если он ничего не создает в таблице?

First or create создает

трансляция fwdays

сейчас

Добрый день. Подскажите, у меня в базе есть поле с уникаольным значением. Я вношу в базу по одной записи. Если уже такая запись имеется, мне вылетает ошибки SQL. Как правильно в ларе делать проверку? перед записью производить поиск в базе и если значение найдено, то выдавать сообщение, еси нет то заносить? или есть более простой вариант?

У валидатора есть проверка unique. Туда же можно дать исключение, чтобы при редактировании этой же записи не ругался

First or create создает

Ну все равно это лишнее, зачем делать выборку, если она нам не нужна

подскажите, а shuffle как то отдеально работает в Ларе?

public function index() { $tags=Tag::all(); $end_tags = count($tags); shuffle($tags); return view('index',['tags' => $tags, 'end_tags' => $end_tags]); }

Разве Tag::all() не коллекцию вернет?

Я в соседнем чате уже это сказал

А, я не читал тот чат

Я в соседнем чате уже это сказал

у меня выходит такой массив {{ $tag->id }} {{ $tag->tag }} {{ $tag->category }}

мне нужен array_multisort такой тип сортировки?

Я ж там написал, сделай $tags->toArray() и shuffle ему

у меня выходит такой массив {{ $tag->id }} {{ $tag->tag }} {{ $tag->category }}

К элементам массива нельзя обращаться через -> если что. Это признак объекта самый явный)

Я ж там написал, сделай $tags->toArray() и shuffle ему

ок щас

К элементам массива нельзя обращаться через -> если что. Это признак объекта самый явный)

в доках везде, получается они всегда объект передают? @foreach ($users as $user) <p>This is user {{ $user->id }}</p> @endforeach

Да. Просто он реализует нужные интерфейсы.

Iterable, countable

Iterable, countable

Все спасибо, потумил минут , нашел как сделать) public function index() { $tags=Tag::all('tag')->toArray(); $end_tags = count($tags); shuffle($tags); return view('index',['tags' => $tags, 'end_tags' => $end_tags]); }

А чего туптиь, я ж сразу сказал - toArray сделать)

А чего туптиь, я ж сразу сказал - toArray сделать)

я делал $tags=Tag::all('tag'); $tags->toArray();

А надо было $tags = $tags->toArray()

ну да

ну или лучше - как ты сделал в итоге

теперь осталось сделать вывод только 30 тэгов

кстати, можно сделать, что бы только 30 записей бралось с таблицы? Tag::all('tag');

вроде можно.

Ну так залезь в доку же) там описано как брать записей, сколько надо

Ну так залезь в доку же) там описано как брать записей, сколько надо

да не проще сделал

@for ($key = 0; $key < 30; $key++) #{{ $tags[$key]['tag'] }} @endfor

Не делай так)

Добрый день...не могу вкурить как в sleepinowl сделать загрузку изобажений

Не делай так)

Почему?

Почему?

Не надо выбирать из базы больше, чем надо. Не надо такую логику во view помещать

Не надо выбирать из базы больше, чем надо. Не надо такую логику во view помещать

Так мне же надо выбрать все записи и уже рандомить их

Select * from table order by rand?

Мне не надо брать 30 записей. Мне надо взять все их отсортировать и вывести 30

Limit 30

так отсортировать или случайные?

Select * from table order by rand?

Случайные.

Я понял, передать на мускл.

Рандом

ну и даже если так надо - ограничивай выборку в контроллере а не во вью

ну и даже если так надо - ограничивай выборку в контроллере а не во вью

Логику из шаблона забрать, а в шаблоне только фореч?

Да

Ок. Спасибо. Вечером доделаю инструментарий для автопостинг в Инстаграме

Подскажите реализацию множественной загрузки изображения

Может есть готовый плагин, js скрипты. Требуется для админки, загрузка изображений товара

есть кто живой?

а что

есть вопрос по БД уровня старшеклассника, видимо, несовместимый с моей головой

проще написать его тут

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

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

ERROR: S client not available

а ещё когда покупатель кладёт в корзину товар или оплачивает заказ - часть булавок висит на складе, а часть в корзине/заказе

я сделал "набор". это product_set

когда одного товара сколько-то штук. сделал через junction table, как видно

это которая __map_2

вопрос - можно ли лучше, чем есть сейчас?

меня смущает как минимум то, что в справочной таблице (junction table) пришлось добавить поле product_qty

нормальная ли это практика и что в целом можете сказать о данном решении?

заранее спасибо.

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

таким образом из схемы спокойно убираем _map_2, в product добавляем qty, в product_set добавляем позиции для product_id и qty нужных ну и собственно все

мне нравится ход мыслей, перечитываю снова

всё отлично. теперь добавлю условие, которое сразу не описал

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

т.е. мне надо будет добавить промежуточно справ. таблицу между product_set и cart, как и между product_set и order

а это уже то, от чего я с трудом, но ушёл вроде бы

т.к. хочется макс. просто и элегантно, а не через 20 табл. делать

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

я понял. схема это учитывает. product_set #1 product_id: 1, qty: 10 product_id: 2, qty: 5 product_set #2 product_id: 4, qty: 2 product_id: 8, qty: 6 в корзине у нас 2 продакт сета - 1 и 2. когда делаем заказ со склада списываем следующее кол-во позиций: product_id: 1 - 10 штук product_id: 2 - 5 штук product_id: 4 - 2 штуки product_id: 8 - 6 штук

у product_set id не уникальный

может быть 10 позиций для первого сета прописано

каждая позиция - product_id в нужном кол-ве

про то, чтобы сделать таблицу product стоковой - да. а вот как реализовано что у нас в корзине 2 сета?

как понимаю в корзину добавляются не товары а готовые сеты. значит мы просто на сайте выбрали сет 1 (в котором такие-то позиции в таком-то кол-ве) и сет 2 (в котором такие-то позиции в таком-то кол-ве)

корзине _присвоен_ один сет

только так. там отношение 1:1

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

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

кхм. я теперь понял что надо. я тогда опишу как это сделано нормально в одном магазине. у клиента может быть много корзин. каждая корзина - в твоем представлении это "сет". при процессинге корзины - она списывается с остатков и переходит в ордеры.

то есть я бы расширил таблицу корзины и избавился и от таблице сетов и от map

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

ну дык. есть же история заказов