ユーザーが登録するために 2 つ以上の画面に入力する必要がある Rails アプリに取り組んでいます。登録データは、2 つのテーブルの 2 つまたは 3 つのレコードにまたがっています。
もちろん、ユーザーは登録が完了する前に救済することができます。これは、必須列の null エントリとして検出できます。
これらの部分的に完了した登録を合理的な遅延 (数時間) 後にクリーンアップする「Rails Way」とは何ですか?
違いが生じる場合に備えて、私は Heroku にデプロイしています。
ユーザーが登録するために 2 つ以上の画面に入力する必要がある Rails アプリに取り組んでいます。登録データは、2 つのテーブルの 2 つまたは 3 つのレコードにまたがっています。
もちろん、ユーザーは登録が完了する前に救済することができます。これは、必須列の null エントリとして検出できます。
これらの部分的に完了した登録を合理的な遅延 (数時間) 後にクリーンアップする「Rails Way」とは何ですか?
違いが生じる場合に備えて、私は Heroku にデプロイしています。
それが「レールウェイ」かどうかはわかりませんが、rakeタスクを作成し、cronジョブを介して定期的に実行することで、おそらくあなたの説明には十分だと思います。テストに興味がある場合は、他のコードと同じようにrakeタスクをテストすることもできます。
「進行中」のユーザー用に別のテーブルを用意することを検討しましたか? それを切り刻んで、完成したら周りに広げます。
update_at
次に、進行中のテーブルで1 日以上経過したものをすべて削除するだけで、放棄されたユーザーをクリーンアップできます。これは、rake タスクを実行する毎日の cron ジョブ (またはスケジューラなど) で処理できます。これにより、終了するまで実際にはユーザーではないため、終了するまでログインできなくなります。
副作用として、終了するまで実際のユーザーではないため、終了するまでログインできません。current_user
もちろん、1 つのコントローラー内で処理を微調整する必要があるかもしれません。
この種のアプローチは、パラノイアの余分なレベルとして、必須の列に NOT NULL 制約を追加できることも意味します。