ORMとの連携 faker は CakePHP や Laravel の ORM と連携することができる(!?) 試してみたところ、連携というよりは ORM を通して、実際に DB に値を格納してくれるっぽい。 例えば CakePHP3 で使うならこんなふうに。 $faker = \Faker\Factory::create('ja_JP'); $populator = new \Faker\ORM\CakePHP\Populator($faker); $populator->addEntity('Users', 5, [ 'name' => function() use ($faker) { return $faker->name; }, 'prefecture' => function() use ($faker) { return $faker->prefecture; }, 'cre
さてさて、Laravelの提供する機能で特に便利なのが「Query Builder」、つまりデータベースの操作といっていいと思います。 Laravelに限らずですが、フレームワークがなかった頃はいちいちDBに接続するコードを実行し、それから冗長なSQL文を繰り返し記述したものですけど、現在はおかげさまでホントにすっきりしたコードで開発できるようになりました。 ということで、今回はLaravelの根本的な機能のDB操作の中から、データ取得にフォーカスした全実例を紹介します。 【動作環境】 Laravel 5.6 MySQL 5.7 データ取得の基本 get()で全てのデータを取得する Laravelでデータベースからデータ取得する基本は以下のようになります。 $items = \DB::table('items')->get(); // 全てのデータが取得できる データベース名をtable(
laravel 5.2 で、バリデーションルールに配列を表す .* というプレースホルダーが使えるようになりました。 例えば、次のような商品オプションのバリデーションを考えます。 入力行の追加UIやドラッグ&ドロップによるソートはjQueryなどで実装することにします(laravel から離れるので解説は省きます) この場合、項目数がいくつになるかわからないので、エレメントの属性名を name="option_name[{{$id}}]" などとし、配列を返すように作りますよね。 リクエストは次のようなものになるでしょう。配列のキーは編集データに依存しますので不定です(ここでは仮に 11, 12, 13 としました) Array ( [option_id] => Array ( [11] => Y [12] => Y [13] => Y ) [option_name] => Array (
リレーションについてはこれ Eloquent:リレーション 5.1 Laravel こんなんできる 任意のポストについたコメントを取得する DB posts id|post| 1|aaa| 2|bbb| comments id|post_id|string| 1|1|aaaa| 2|1|iiii| 3|2|uuuu| ポスト1には、aaaa,iiiiの2つのコメント。 ポスト2には、uuuuという1つのコメント。 $comments = App\Post::find(1)->comments; foreach ($comments as $comment) { echo $comment->string . "\n"; } aaaa iiii ポスト1のコメント取得出来た。 リレーションを設定すると、面倒なqueryでのleftJoinとか書かなくていい。 書き方 公式コピペ。 <?php
PHPUnitや他のxUnit系に assertThat という少し複雑な条件を書くことができるアサーションがあります。 PHPUnitで、たまに使う assertThat を紹介してみようかなと思います。 環境構成 PHPUnit 4.8.6 PHP 5.6.13 assertThat使い方 assertThatは、アサーションの中に条件を指定できるというような感じです。 その他のassertXXXで、できないかというとほとんどできると思います。 できるけれども、assertThat使ったほうが分かりやすかったりテストを書くのが楽な場合は、私はこちらを使います。 サンプルコード <?php class Test extends PHPUnit_Framework_TestCase { /** @test */ public function 配列が指定したキーを保持していること() {
Laravelのバリデーションって書きやすくて良いいですよね。 かゆいところに手が届く感じ。 どんな使い方が出来るかはドキュメントに詳しく記載されているのですが、 バリデーションルールの指定方法には大きく2タイプあるものの片方しか紹介されていなくて、いつも調べる事になるのでメモメモ。 複数条件をパイプで繋ぐタイプ これはドキュメントにも例が載っているタイプ。 $rules = [ 'name' => 'required|max:40', 'gender' => 'required|in:male,female', 'age' => 'digits_between:0,150', 'use_discount' => 'boolean', 'coupon' => 'required_if:use_discount,1|regex:/^[0-9a-zA-Z]{20}$/', ]; 各情報に対して
こんにちは!料理があまり得意ではなく、たまに味付けに失敗するmuramatsuです。味見をすればいいのですが、味見をしていると味がだんだん分からなくなってくるので、誰かに聞くようにしました。 さてPHPでは、プログラム実行中に発生する例外エラーに対して処理を行うことができます。この記事では、Exceptionクラスの使用方法が知りたい、例外メッセージや例外コードを取得する方法が知りたいという基本的な内容から、 などが発生する可能性があります。こうした事項はエラー(例外)として考えられ、適切な処理をしなければなりません。例外に対して何も処理を行わないと、例外が発生した時、プログラムはそこで異常終了してしまいます。それを防ぐために、例外に応じた例外処理を行います。 例外が発生することを、例外が投げられる(throwされる)といいます。 書き方: <?php throw new Exceptio
Laravelでは、OAuthによるAPI認証を実現するためにPassportというパッケージが提供されています。 また、認可の仕組みとしてPolicyがあります。 しかし、それぞれを単純に実装しただけだと単体テストはうまくいくのに通常のリクエストではうまくいかずはまったので今回はそれの解決法を書きます。 Laravel 5.6です。 Passportの実装 公式サイトの手順に従ってPassportを導入します(詳しい手順については今回は省略)。 Passportの設定が完了したら、コントローラなどを作成します。 今回は適当にItemというモデルを定義してそれに関するもろもろ作りました。 簡易化のためにコントローラはGET用のメソッドのみ作成しています。 use Illuminate\Support\Facades\Schema; use Illuminate\Database\Schem
PhpStormネタをまとめるときに、Docker環境の設定の話は分離しておきたいと思ったので独立した記事にする。 はじめに Docker を利用すると、Dockerfileやdocker-compose.ymlを使って、PHPアプリ開発環境の設定を手軽にチームで共有できるため、プロジェクトのコードをgit cloneしたあとにすぐ起動できる環境を用意するのに適している。 またPhpStormは、Dockerを使って用意したPHPアプリ開発環境と連携できる機能がある。 そこで、PhpStormの連携機能や、PHPコード自体を手軽に試せるよう、シンプルなPHP CLI環境とXdebugデバッグできるWebサーバ環境について説明する。 目次 はじめに 目次 PhpStormと連携するCLI環境を用意する 設定方法 Xdebugでデバッグできる最低限のWebサーバを用意する 設定方法 Docke
class User extends Model { public function scopeActive($query) { $query->where('active', true); } }
insertやcreateメソッドでテーブルのカラムに値を挿入する事ができます。 そのような複数代入をする際に、予期せぬ代入が起こることを防ぐために、 モデルへfillableかguardedを設定する必要があります。 「予期せぬ代入」って? 複数代入による予期せぬ代入とは、製作者が意図していない代入のことです。 ユーザーから変えてほしくない値(例えばidや管理者権限を管理するカラムなど) を自由に変えることができてしまったら困ってしまいますよね😭😭😭 事件になります。 入力によって変動する値を安全に管理するために、以下の指定が必要となります。 【方法】fillableとguardedの設定 $fillable - ホワイトリスト_複数代入時に代入を許可する属性を配列で設定
どうも、いっき(@kzkohashi)です。 Laravelを使い始めて1年くらいたちそうなので、いくつか試している実装パターンの感想でも書こうと思う。 今回は、Repositoryパターンについて書く。 ---追記--- リポジトリーパターンを採用しつつバリューオブジェクトについても書いた。 kzkohashi.hatenablog.com また、Laravel MeetupでDDDについても発表したまとめ。 kzkohashi.hatenablog.com Repositoryパターンとは? Repositoryパターンとはビジネスロジックとデータ操作のロジックを分離し、データ操作のロジックを抽象化するパターンと認識してる。 例えばユーザーが新規登録したとして、今までだと View -> UserController -> UserSerive(ビジネスロジック/データ操作) View
やりたいこと required_if等で 「◯◯が▲▲の場合、□□も指定してください」で、▲▲部分が値で直接表示されるのでカスタムしたい。 ただし、Validatorファサードでカスタムはしたくない。 想定 userテーブルにroleカラムがあり、roleが1(承認者)の場合は承認対象ページも入力させたい。 コード nameにprefixでテーブル名をつけいている場合。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く