いまお手伝いしている開発で、bundle exac rspecしたけどエラーで真っ赤かになりましたと。(ちなみに配下のindex.htmlを直してもbundle exac rspecするたびにファイルが生成されるので実装コード自体を直さなければエラーは出まくりますよと)
コードを読んでもどこでエラーが出ているのかわからないのですが
ヒントをもらいまくって
どうやらバリデーションのところが問題らしいと。
そして、バリデーションってテックアカデミーの時とかは、ああなんか制限するやつってくらいしか覚えていなかったけれど
それどころじゃないらしいのでしっかり調べてみることにしました。
まずバリデーションとは
バリデーションは、正しいデータだけをデータベースに保存するために行われます。たとえば、自分のアプリケーションで、すべてのユーザーには必ず電子メールアドレスとメーリングリストアドレスが必要だとします。正しいデータだけをデータベースに保存するのであれば、モデルレベルでバリデーションを実行するのが最適です。
モデルレベルでバリデーション???
ということは他レベルでのバリデーションもあるということですね?
どういうことでしょうか??
休憩。 pic.twitter.com/wurisnFman
— EngineerWmn (@engineerman8) August 27, 2018
他も見てみよう
- データベース制約やストアドプロシージャを使用すると、バリデーションのメカニズムがデータベースに依存してしまい、テストや保守がその分面倒になります。ただし、データベースが (Rails以外の) 他のアプリケーションからも使用されるのであれば、データベースレベルである程度のバリデーションを行なっておくのはよい方法です。また、データベースレベルのバリデーションの中には、使用頻度がきわめて高いテーブルの一意性バリデーションなど、他の方法では実装が困難なものもあります。
- クライアント側でのバリデーションは扱いやすく便利ですが、一般に単独では信頼性が不足します。JavaScriptを使用してバリデーションを実装する場合、ユーザーがJavaScriptをオフにしてしまえばバイパスされてしまいます。ただし、他の方法と併用するのであれば、クライアント側でのバリデーションはユーザーに即座にフィードバックを返すための便利な方法となるでしょう。
- コントローラレベルのバリデーションは一度はやってみたくなるものですが、たいてい手に負えなくなり、テストも保守も困難になりがちです。アプリケーションの寿命を永らえ、保守作業を苦痛なものにしないようにするためには、コントローラのコード量は可能な限り減らすべきです。
データベース、そしてコントローラ も出てきました。
バリデーションの実行時の動作って結局どうなるの?
バリデーションのコードを書くと、例えば文字が入力足りなかったりしたら赤字でエラーが表示されたりとかするために書くんでしょ?
とだけ(ざっくり!)思っていたんですが、中ではもっと複雑な動作がなされていたようです。
新規レコードを作成して保存すると、SQLの
INSERT
操作がデータベースに送信されます。既存のレコードを更新すると、SQLのUPDATE
操作が送信されます。バリデーションは、SQLのデータベースへの送信前に行うのが普通です。バリデーションのいずれかが失敗すると、オブジェクトは無効(invalid)とマークされ、Active RecordでのINSERT
やUPDATE
操作は行われません。これにより、無効なオブジェクトがデータベースに保存されることを防止します。オブジェクトの作成、保存、更新時に特定のバリデーションを実行することもできます。
なんというか、まとめるにまとめられない。
今日は風邪をひいて声が出ないので引きこもってずっとPC叩いてました。
でも人間の集中できる時間って短いですね。。
Rspec,git diff etc...今日も自分の知らなかったことをどんどん使いました。脳みそが痒いです。頑張る。。。
声が完全につぶれてしまったので
— EngineerWmn (@engineerman8) August 28, 2018
イベントに行かずに
引きこもってプログラミングします。
体は平気だからちょっと身体動かしてこようかな。。🤔
twitterアカウント作り直しました!
そしてUdemy がセール中なのもあり今日はVue.jsのコースも買ってしまいました。。。
1200円セール中!