У меня есть модель оплаты, которая принадлежит модели FinancialGoal, которая, в свою очередь, принадлежит модели пользователя. У меня определены следующие методы отношений:
Модель оплаты:
public function financialGoal()
{
return $this->belongsTo(FinancialGoal::class);
}
public function user()
{ //not sure this is correct
return $this->hasOneThrough(User::class, FinancialGoal::class);
}
Модель пользователя:
public function financialGoals()
{
return $this->hasMany(FinancialGoal::class);
}
public function payments()
{
return $this->hasManyThrough(Payment::class, FinancialGoal::class);
}
Модель финансовой цели:
public function user()
{
return $this->belongsTo(User::class);
}
public function payments()
{
return $this->hasMany(Payment::class);
}
Вопрос в том, как определить обратный метод оплаты в модели пользователя, в модели оплаты. В какой-то момент я использовал одно из этих двух определений модели оплаты, и оба работают, но просто не уверен, можно ли использовать одно из них, и хотел бы узнать правильный подход.
public function user()
{
return $this->financialGoal->user();
}
public function user()
{ // had to ignore static analysis error for this but it returns the relationship
return $this->financialGoal->belongsTo(User::class);
}
Судя по вашим отношениям, я предполагаю, что это ваша структура таблицы.
Ваши первые user
отношения по модели Payment
( $this->hasOneThrough(User::class, FinancialGoal::class)
) неверны, поскольку вам нужно обратное ей. Это не очень хорошо документировано в документации Laravel, но если вы поиграете со всеми параметрами метода hasOneThrough
, вы сможете достичь своей цели. Отношения с пользователем будут выглядеть так
class Payment extends Model
{
public function user()
{
return $this->hasOneThrough(User::class, FinancialGoal::class, 'id', 'id', 'financial_goal_id', 'user_id');
}
}
Это будет лучше, чем две другие ваши попытки, поскольку ее можно легко загрузить с помощью Eager и она не зависит от других существующих связей.
@Adefowowe Что касается обратного, возможно, я неправильно выразился. Это похоже на то, что belongsTo
является противоположностью hasOne
или hasMany
, это было мое намерение. Формулировку я взял из этого выпуска
Я ожидал, что любая реализация будет следовать документации с точки зрения параметров метода, но это не так. Ключи не соответствуют тому, что указано в документации.
Спасибо за это, получил такое же предложение от ChatGPT и пытался согласовать его с документами. Хотя я не понимаю, почему это инверсия.