вот че выводится по итогу

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

Привет котаны

Есть две модели

Дискуссия и ответы к ней

Дискуссия связана с ответами

public function answer() { return $this->hasMany('App\Models\DiscussionsAnswers', 'discussions_id', 'id'); }

ответы с дискуссией

public function discussion() { return $this->belongsTo('App\Models\Discussions'); }

Я пытаюсь создавать ответ через связь $this->discus->where('id', $TopicID)->answer()->create([ 'user_id' => Auth::user()->id, 'ip' => $IP, 'status' => 1, 'text' => $Text, ]);

Чтобы работал touch

А меня ругает

Call to undefined method Illuminate\Database\Eloquent\Builder::answer()

Где я не прав?

после where first

о, да, спасибо

второй вопрос теперь

в модели Ответы

protected $touches = ['discussion']; public function discussion() { return $this->belongsTo('App\Models\Discussions'); }

Но модель Дискуссии апдейт_тайм не обновляется

Почему?

судя по доке только при изменении модели Ответы

не при создании

блин +_+

а как делать тоуч тогда?

вручную?

или повесить обзервер на модель

до этого у мня тупо поле crunch было и я там 1 апдейтил

и там обновлять

или повесить обзервер на модель

а кинь в меня докой поззязя

https://laravel.com/docs/5.7/eloquent#observers

?

А можно ещё вопрос? А можно тогда через touch() как-то делать, чтобы не городить огород?

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

Можно. В обзервере и делай

А можно ещё вопрос? А можно тогда через touch() как-то делать, чтобы не городить огород?

https://laravel.com/docs/5.7/eloquent-relationships#touching-parent-timestamps

https://laravel.com/docs/5.7/eloquent-relationships#touching-parent-timestamps

Работает на апдейт, а не на создание новых строк.

Меня интересует вызов метода отдельно ещё.

цены у разных цветов могут отличаться?

нет не будут отличаться

many to many?

Создаешь модель Color, таблицу colors и color_product, между моделями Product и Color отношения many to many. При фильтрации делаешь запрос с whereHas('color', function($query) use ($request) {$query->where('name', $request->name )})

Но, как мне кажется, лучше будет сделать офферы, и связь будет не с Product, а с офером. У продукта к оферу отношение one to many, а уже у оферов, например, по EAV будет и Color, и я вижу у вас там Quantity, и если нужно будет, то и другие опции...

Как сгенерировать route по его имени но с указанным ему доменом?

По умолчанию хелпер route('name') возвращает путь в текущем домене запроса

то есть подтягивает данные из $request

Пока единственное, что придумал - route('name', [], false) - сгенерировать относительный путь и подставить ему нужный домен

Насколько правильно наследовать таблицы базы данных? В родительской:имя, фамилия, почта, телефон, пароль. В дочерних - другие поля + ссылка на родительскую 1к1?

Насколько правильно наследовать таблицы базы данных? В родительской:имя, фамилия, почта, телефон, пароль. В дочерних - другие поля + ссылка на родительскую 1к1?

Я наверное хранил бы другие в json

В базе хранить Это бредовое решение, так как вдруг свичнули домен или переехали и все упало

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

Я наверное хранил бы другие в json

Так нужны сортировки, фильтры, поиск по полям. Выносить потом - не очень. А база - мускуль.

Так нужны сортировки, фильтры, поиск по полям. Выносить потом - не очень. А база - мускуль.

https://stackoverflow.com/a/39163928 выглядит вполне юзабельно) и главное без регулярок))

На практике непонятно как с этим работается. Но в mysql целый раздел с функциями для работы с json данными

Ссылка на документацию там же

Я сделал с наследование, но теперь сомневаюсь, что это правильно. Во всяком случае, теперь стало сложнее. Сложность появилась при создании, изменении пользователя. А именно, как дотягиваться до полей родительской таблицы. Приходится постоянно джоинить что то. Возможно, придется перейти на носкуль.

Перейти на носкуль потом- это 2 сложность. Придется переписать без наследования. Меньше сложностей

Я сделал с наследование, но теперь сомневаюсь, что это правильно. Во всяком случае, теперь стало сложнее. Сложность появилась при создании, изменении пользователя. А именно, как дотягиваться до полей родительской таблицы. Приходится постоянно джоинить что то. Возможно, придется перейти на носкуль.

А что мешает через связь то изменять данные?

Я сделал с наследование, но теперь сомневаюсь, что это правильно. Во всяком случае, теперь стало сложнее. Сложность появилась при создании, изменении пользователя. А именно, как дотягиваться до полей родительской таблицы. Приходится постоянно джоинить что то. Возможно, придется перейти на носкуль.

Не обязательно join юзать, можно сразу выбирать из двух таблиц

Не обязательно join юзать, можно сразу выбирать из двух таблиц

Подскажи?

Подскажи?

select ... from ‘users’, ‘rows’ where ‘users’.id = ‘rows’.user_id

Простой пример

Подскажи?

Связи. Ты получаешь родителя и указываешь связь. После может сделать что-то типа user->relation->country = data. И сохранить связь.

Не знаю сохраняется ли если вызывать только user->save

select ... from ‘users’, ‘rows’ where ‘users’.id = ‘rows’.user_id

не, так не надо делать; только через join

Связи. Ты получаешь родителя и указываешь связь. После может сделать что-то типа user->relation->country = data. И сохранить связь.

При таком подходе, за все отвечает модель/контролёр юзера. В них нужно писать доп проверки: кого регистрировать, пользователя или админа или продавца или медведя. Если взваливать регистрацию на каждого из этих ребят, то получится такое: Надо зарегистрировать медведя. Надо вывести поля таблицы юзер(имя, фамилия, пароль и тд) и поля для медведя + отношения для user и отношения для медведя. Он отправил форму. в реквестах валидация наследуются от юзера + валидация медведя. Потом надо распихать в данные в таблицы. Часть данных запихать в юзера, часть в медведя, часть в отношения(не обязательно). Что бы это сделать, надо понять, а какие поля для юзера, какие для медведя. Жёстко привязывается к столбцам таблицы. Плюс дотягиваться не красиво(репозитория нет). Нужно добавить новые поля? Лезь в код, ищи там. Я ещё не писал про поиск, поиск по нескольким полям, сортировку, фильтры, пагинцаю? Если я ошибаюсь, поправьте. Но пока готов избавится от наследования таблиц.

При таком подходе, за все отвечает модель/контролёр юзера. В них нужно писать доп проверки: кого регистрировать, пользователя или админа или продавца или медведя. Если взваливать регистрацию на каждого из этих ребят, то получится такое: Надо зарегистрировать медведя. Надо вывести поля таблицы юзер(имя, фамилия, пароль и тд) и поля для медведя + отношения для user и отношения для медведя. Он отправил форму. в реквестах валидация наследуются от юзера + валидация медведя. Потом надо распихать в данные в таблицы. Часть данных запихать в юзера, часть в медведя, часть в отношения(не обязательно). Что бы это сделать, надо понять, а какие поля для юзера, какие для медведя. Жёстко привязывается к столбцам таблицы. Плюс дотягиваться не красиво(репозитория нет). Нужно добавить новые поля? Лезь в код, ищи там. Я ещё не писал про поиск, поиск по нескольким полям, сортировку, фильтры, пагинцаю? Если я ошибаюсь, поправьте. Но пока готов избавится от наследования таблиц.

Что мешает почитать доки по отношениям в ларе?

Что мешает почитать доки по отношениям в ларе?

Ничего. Читаю не первый день.

Поиск по связям через whereHas

Что мешает почитать доки по отношениям в ларе?

На самом деле это многим не под силу, судя по всему

Поиск по связям через whereHas

Знаю, использую

На самом деле это многим не под силу, судя по всему

Немного сложно вначале, много гуглил.

Потом не составляет вовсе сложностей

Вы сами что используете? Один использует json в мускуле. Я понял. Остальные как делают?

Связями

Вы сами что используете? Один использует json в мускуле. Я понял. Остальные как делают?

Лара билдер использует. Запрос собирается сам

Вообще по ситуации, от полей зависит

При таком подходе, за все отвечает модель/контролёр юзера. В них нужно писать доп проверки: кого регистрировать, пользователя или админа или продавца или медведя. Если взваливать регистрацию на каждого из этих ребят, то получится такое: Надо зарегистрировать медведя. Надо вывести поля таблицы юзер(имя, фамилия, пароль и тд) и поля для медведя + отношения для user и отношения для медведя. Он отправил форму. в реквестах валидация наследуются от юзера + валидация медведя. Потом надо распихать в данные в таблицы. Часть данных запихать в юзера, часть в медведя, часть в отношения(не обязательно). Что бы это сделать, надо понять, а какие поля для юзера, какие для медведя. Жёстко привязывается к столбцам таблицы. Плюс дотягиваться не красиво(репозитория нет). Нужно добавить новые поля? Лезь в код, ищи там. Я ещё не писал про поиск, поиск по нескольким полям, сортировку, фильтры, пагинцаю? Если я ошибаюсь, поправьте. Но пока готов избавится от наследования таблиц.

Не вижу никакой проблемы. С Orm ларавеля работать с базой одно удовольствие. И да + к сообщению где советуют ознакомится с разделом отношений в ларке.

Я делал и так и так и так. С текущей реализацией у меня сложности. Возможно, я не правильно делаю. Поэтому ищу ответы компетентных. А вы отправляете доки читать по wherehas.

В обычных запросах использую join

Вы сами что используете? Один использует json в мускуле. Я понял. Остальные как делают?

Звучит как-то с обсуждением.)

Звучит как-то с обсуждением.)

Осуждением? Нет, это то же путь. Но сейчас его не можем придерживаться

Покажи пример твоих двух таблиц

Я делал и так и так и так. С текущей реализацией у меня сложности. Возможно, я не правильно делаю. Поэтому ищу ответы компетентных. А вы отправляете доки читать по wherehas.

Нет тебе советуют https://laravel.com/docs/5.7/eloquent-relationships полностью прочесть) и найти применение в своей задаче + любите модификации данных ты можешь делать в уже полученной коллекции и всех её связях и в лббый момент вызвать save и оно тебе сохранит Изменения конкретной записи а связях или в родительской моделе.

На двух проектах реализованы два различных типов юзерей (например, для физических и юридических лиц)

Правильно спроектировать бд это целая наука

В итоге у меня таблица с общими данными и две под отдельные поля для разных типов

Они сейчас простые: User: Namme,sername,phone, password... Customer: Search_query_count, active, user_id... Staff: Position_id, fired, user _id... Дальше появятся новые сущности. Настройки к этими сущностям( опять же 1к1)

Человек хочет сделать правильно

+