Laravel Eloquent: доступ к свойствам и динамическим именам таблиц

Я использую структуру Laravel, и этот вопрос напрямую связан с использованием Eloquent в Laravel.

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

• gamedata_2015_nations
• gamedata_2015_leagues
• gamedata_2015_teams
• gamedata_2015_players

я мог бы, конечно, иметь одну большую таблицу со столбцом года, но с более чем 350 000 строк каждый год и много лет, чтобы иметь дело с я решил, что было бы лучше разделить их на несколько таблиц, а не 4 огромные таблицы с дополнительным " где " по каждому запросу.

так что я хочу сделать имейте по одному классу для каждого и сделайте что-то вроде этого в классе репозитория:

public static function getTeam($year, $team_id)
    {
        $team = new Team;

        $team->setYear($year);

        return $team->find($team_id);
    }

я использовал это обсуждение на форумах Laravel, чтобы начать:http://laravel.io/forum/08-01-2014-defining-models-in-runtime

пока у меня есть это:

class Team extends IlluminateDatabaseEloquentModel {

    protected static $year;

    public function setYear($year)
    {
        static::$year= $year;
    }

    public function getTable()
    {
        if(static::$year)
        {
            //Taken from https://github.com/laravel/framework/blob/4.2/src/Illuminate/Database/Eloquent/Model.php#L1875
            $tableName = str_replace('', '', snake_case(str_plural(class_basename($this))));

            return 'gamedata_'.static::$year.'_'.$tableName;
        }

        return Parent::getTable();
    }
}

это, кажется, работает, однако я беспокоюсь, что это не работает в правильном направлении.

поскольку я использую ключевое слово static, свойство $year сохраняется в классе вместо каждого отдельного объекта, поэтому всякий раз, когда я создаю новый объект, он все еще содержит свойство $year на основе последнего времени, когда он был установлен в другом объекте. Я бы предпочел, чтобы $year был связан с одним объектом и должен был устанавливаться каждый раз, когда я создавал объект.

теперь я пытаюсь отслеживать, как Laravel создает красноречивые модели, но действительно изо всех сил пытается найти правильное место для этого.

например, если я изменю его на это:

class Team extends IlluminateDatabaseEloquentModel {

    public $year;

    public function setYear($year)
    {
        $this->year = $year;
    }

    public function getTable()
    {
        if($this->year)
        {
            //Taken from https://github.com/laravel/framework/blob/4.2/src/Illuminate/Database/Eloquent/Model.php#L1875
            $tableName = str_replace('', '', snake_case(str_plural(class_basename($this))));

            return 'gamedata_'.$this->year.'_'.$tableName;
        }

        return Parent::getTable();
    }
}

это работает просто отлично, когда пытается получить одну команду. Однако с отношениями это не работает. Это то, что я пробовал с отношениями:

public function players()
{
    $playerModel = DataRepository::getPlayerModel(static::$year);

    return $this->hasMany($playerModel);
}

//This is in the DataRepository class
public static function getPlayerModel($year)
{
    $model = new Player;

    $model->setYear($year);

    return $model;
}

снова это работает абсолютно нормально, если я использую static::$year, но если я попытаюсь изменить его, чтобы использовать $this->year, то это перестает работать.

фактическая ошибка связана с тем, что $this - >year не установлен в getTable (), так что родительский метод getTable() вызывается и неправильно возвращено имя таблицы.

моим следующим шагом было попытаться выяснить, почему он работает со статическим свойством, но не с нестатическим свойством (не уверен в правильном термине для этого). Я предположил, что он просто использует static::$year из класса Team при попытке построить отношения с игроком. Однако это не так. Если я попытаюсь заставить ошибку с чем-то вроде этого:

public function players()
{
    //Note the hard coded 1800
    //If it was simply using the old static::$year property then I would expect this still to work
    $playerModel = DataRepository::getPlayerModel(1800);

    return $this->hasMany($playerModel);
}

теперь происходит то, что я получаю сообщение об ошибке gamedata_1800_players не найден. Возможно, это и не удивительно. Но это исключает возможность того, что Eloquent просто использует свойство static::$year из класса Team, поскольку оно явно устанавливает пользовательский год, который я отправляю методу getPlayerModel ().

Итак, теперь я знаю, что когда $year установлен в отношениях и установлен статически, то getTable() имеет доступ к нему, но если он установлен нестатически, то он где-то теряется, и объект не знает об этом свойстве вызывается time getTable ().

(обратите внимание на важность его работы при создании нового объекта и при использовании отношений)

Я понимаю, что я дал много деталей сейчас, поэтому, чтобы упростить и уточнить мой вопрос:

1) Почему static::$year работает, но $this - > year не работает для отношений, когда оба работают при создании нового объекта.

2) есть ли способ, которым я могу использовать нестатическое свойство и достичь того, что я уже достижение использования статического свойства?

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

пример:

    //Get a League from the 2015 database
    $leagueQuery = new League;

    $leagueQuery->setYear(2015);

    $league = $leagueQuery->find(11);

    //Get another league
    //EEK! I still think i'm from 2015, even though nobodies told me that!
    $league2 = League::find(12);

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