Laravel 5.3 タイムスタンプのDB項目名の指定
Laravel 5.3に更新して、Eloquentのモデルの設定において嬉しいこと発見しました。 LaravelのEloquentでは、指定のDBテーブルにおいて、作成日時と編集日時に、規定のcreated_atとupdated_atの項目名が使用されているなら、いちいち、
Laravel 5.3に更新して、Eloquentのモデルの設定において嬉しいこと発見しました。 LaravelのEloquentでは、指定のDBテーブルにおいて、作成日時と編集日時に、規定のcreated_atとupdated_atの項目名が使用されているなら、いちいち、
このブログを開始してから、もうすでに1年以上。RawのSQLを書いてコードに埋め込む日常から、Eloquentを使用したORMのコードへと日常へと移行しています。Eloquentに関しても、ブログを書き始めた頃からは理解が深まり、洗練されたLaravelのコードを書けるようになってきたこの頃です。 1年前に書いた「マスアサインメントで一括取り込み」のトピックで、EloquentのModelのクラスの属性fillableとguardedの話、1年の経験で学んだことを含めてここでもう一度説明します。
Laravel以前は、ほぼコードにSQL文を埋め込んでいたので、Eloquentよりクエリビルダーの方が馴染みあります。特に複数のDBテーブルをjoinした検索などには。 しかし、各Modelにおいてリレーションを定義していると、それを使用しないのがもったいないように思えてきます。 クエリビルダーでできることをEloquentではどうやるのか、興味ありありになってきました。
Eloquentのcount()の関数を使用して、DBのレコード数を数える作業はよく起こります。
Laravelのマニュアルは、ほどよい説明で気に入っています。長い説明でポイントがつかめなく困ることはそうありません。理解には何回か読むことも必要ですが。 しかし、ときには掲載されるサンプルコードがよく使用されるような例ではなく、逆に混乱してしまうことあります。
Laravelでは、同じことを成し遂げるのにいくつか違う方法で行うことできます。これを便利かと思うかややこしいかと思うかは、人それぞれですが、
ララベルのマニュアルで紹介されている一般的なDBレコードの作成方法は、
前回の投稿「ダーティーなレコード」で、DBレコードが更新されたかどうか、簡単に実験してチェックできるツールを紹介しましょう。