rails で id を BIGINT 型 + primary key + AUTO_INCREMENT する - scramble cadenza
イントロ rails のモデルは自動で id というカラムを作ってくれますが、これは常に INT 型。 BIGINT 型にしようとしたら、結構ハマったのでメモする。 使っている database はmysql です。 (postgresql だとこの罠は回避できるのだろうか？) tl;dr 普通に頑張ると... db:migrate と db:setup の実行結果が異なる migration ファイルの内容が、schema.rb に(一部)反映されないため db:migrate と db:setup の実行結果が異なると、 db:rollback ができなくなるので、辛くなりそう。 db:migrate か db:setup どちらかを使わない、という運用方式もある だが、面倒くさいので、そういうことを意識したくない 解決方法は 2 つ format_schema = :sql kami
How do I load extensions to the Sass::Script::Functions module?
I'm trying to extend the Sass:Script::Functions module, per this recommendation: https://gist.github.com/481261/dd07a52829886ab1ad0875a8895f0100c4b925ab. The question is, where do I place the sass-hex.rb file and do I have to do anything to "load" the module extension? I tried placing the file in config/, but it doesn't seem to be loaded. When I go to the rails console and type Sass::Script::Funct
Railsプロジェクトの初期開発フェーズでのDBスキーマ管理を見直す | Webシステム開発／教育ソリューションのタイムインターメディア
DBのスキーマ、皆様どのように管理されているでしょうか。 Railsを利用されている方の多くは、ActiveRecordのマイグレーションを利用して管理をされているかと思います。 私もいままでいくつかのRailsプロジェクトに関わってきましたが、 ほぼ全てのプロジェクトでActiveRecordのDBマイグレーションを利用してきました。 (一部のプロジェクトはActiveRecordを使っていないため、マイグレーションも独自のものを利用しています) ActiveRecordのマイグレーションでは、DBスキーマ変更の差分情報をマイグレーションスクリプトとして保存しておきます。例えば、新しいテーブル「users」を作成する場合は、下記のようなマイグレーションスクリプトを作成します。 class AddUsers < ActiveRecord::Migration def up # ここにマイグ
テストfixtureの中にerbを書いて動的に生成する - 日々此妄想
テストをちゃんとやろうと試みた事は何度かあった。 でもfixture書くのがダルくてテストを書くまで辿りつけず挫折。 DBのデータからfixtureを作る方法もあるけど、それだとデータが大量すぎて扱いきれない。 でもやっぱりテストはやっておいた方が安心だよなぁと思う今日この頃。 安心というか自分のコードに自信が持てなくなってきたので要所要所はテストしておきたい。 しかしfixtureを書くのがだるい。 そもそもfixtureってDRYじゃない気がする。 そこでふと思いだしたのは「database.yml って DRY じゃないよね。」という話。 http://d.hatena.ne.jp/Rommy/20070731/p1 http://rubyist.g.hatena.ne.jp/Ubuntu/20080709/erb_on_yaml あたりで紹介されてます。 Railsのyamlはer
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
