はじめに Railsでモデルを作ると、テーブル定義上のid列(プライマリーキー)はデフォルトで自動的に連番が付与されるカラム(auto increment値)になります。 とはいえ、idにしたからといって必ずしも連番になるとは限りません。場合によっては「歯抜け(ギャップ)」が発生こともあります。 そのため、「idの最大値=そのテーブルの件数」になるとは限りません。 つまり、こういうデータが作成されることもありうる、ということです(たとえ一度もDELETEされなかったとしても)。 id name

3行まとめ 単純なバリデーション(必須・範囲・文字数など)はHTMLとDB制約、CHECK制約があれば十分であるというのが最近のDHHの主張。 SQLiteではCHECK制約が少し貧弱なため、制約変更の可能性がある場合は従来通りアプリケーションでもバリデーションした方がいい。 Rails初心者はDHHの方法をそのまま採用するのはやめた方が良い。 調べたきっかけ 最近DHHがonce.comでのCampfireをはじめとしたプロダクトで、NULL制約やDB制約で防げるようなRailsのモデルのバリデーションを積極的には利用しないでいるという主張をしている。 DHHの主張を要約すると以下のようになる。[1] HTMLでのバリデーションが優れている 例えば、input type=“email” にしておくとブラウザで勝手にメールアドレス形式ではない場合にエラーにしてデータ送信をしないようにしてく
こんにちは。サーバーサイドエンジニアの三村(@t_mimura39)です。 こちらでご案内した通り、弊社で新しくリリースした「ClinPeer」の裏側をご紹介します。 tech.medpeer.co.jp 今回はClinPeerのバックエンドについての簡単なシステム概要と選定技術の紹介編です。 2024-2025年にrails newをした新鮮なRailsプロジェクトの様子をお楽しみください。 目次 システム概要 rails stats Gemfile 技術選定 Ruby Ruby on Rails Puma ActionPack::CloudfrontViewerAddress Trilogy SolidQueue SolidCache Kaminari Async::HTTP::Faraday Ueki Jb Nokogiri Blazer ActiveHash Flipper Log
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く