Create recent events table #277
Conversation
`/events`を作りたい為、雛形hamlファイルとコントローラー 及び適切に`/events` が表示できるかのテストコードを追加した。
statiscs/providersにはDojoのイベントAPIにアクセスする為の実装がある. 直近のイベント情報を取得する際も、APIアクセスが必要となる為この資産を使いたい。 > statistics 系の資源を使いつつ、直近情報を入手する実装がやっぱり良さそう > ネームスペースが気持ち悪いと思うので、Statisticsの外に出してしまうと良いかもしれないですねぇ。 そこで名前空間をstatiscs/providersからprovidersに変更した
先程のcommitでnamespaceの変更を行った為、Statisticsの名前空間を削除した
…o.jp into add_events_pages
`providers` の名前空間を`statistics` から外した為、require_relativeのパ スを修正した
Statistics::ProvidersからProvides::に名前空間を修正した為 使用しているrakeファイルの名前空間を修正した
テストコードが`Statistics::Providers` を参照していた為、`Statistics` 名 前空間を外した
今回のPRでは`/events` の変更は行わない為削除した
…b module 名前空間を切り分けるために eventservice/providers.rbにproviders.rbを変更し 大本のeventservice.rbを作成した
providersの名前空間をeventservice以下にする為テストコードの名前空間を切り分けた
名前空間を変更した為,lib/tasks/statisticsの使用しているモジュールパスを 変更した
名前空間を変更した物を修正し忘れていた為変更
直近のイベント情報を格納するtableが欲しかった為generateを行った。 スキーマの内容は `event_histories` から参加者を除いた分となっている $ be rails g migration CreateRecentlyEvents dojo_id:integer dojo_name:string service_name:string service_group_id:string event_id:string event_url:string evented_ad:datetime
issues coderdojo-japan#258 にある通り、直近のeventを追加するテーブルを作成した。 ほぼ `event_histories` を模しており、唯一参加人数を保持しない設計となっている。 > 格納先について > event_histories とほぼ同じ構成 > 格納するtaskを statistics と別にする > 3週間ごとに新しいデータを持ってくるようにcron可能なtaskを書く
|
スキーマを追加したので命名規則などに問題がなければ、 |
| t.integer :dojo_id, null: false | ||
| t.string :dojo_name, null: false | ||
| t.string :service_name, null: false | ||
| t.string :service_group_id |
There was a problem hiding this comment.
dojo_event_service.idをdojo_event_service_idとして持てば
dojo_id, dojo_name, service_name, service_group_idの4つは非正規化する必要がなさそうに見えましたがどうでしょうか？
There was a problem hiding this comment.
コメントありがとうございます! dojo_event_service_id だけど情報が取れるので dojo_id などは紐付けなくて良いということでしょうか? (あまり良くわかってないのですが…)
There was a problem hiding this comment.
dojo_event_service_id だけど情報が取れるので dojo_id などは紐付けなくて良いということでしょうか? (あまり良くわかってないのですが…)
はい、その通りです。
テーブルの正規化というやつですね。
ARのモデルでいうと、RecentlyEvent belongs_to DojoEventServiceというassociationを持つことになり、
recently_event.dojo_event_service.dojo_idとかで取得したいカラムの値にたどり着けます。
event_historiesを非正規化した理由はevent_historiesは過去の履歴なので、
dojo_event_serviceの内容が変わった場合に過去の履歴も書き換わってしまうのを避けるため、
ですね😉
このPRで作ろうとしているschemaは近い将来のイベント情報で、dojo_event_serviceが変更されることは殆どないとは思いますが（可能性としてはゼロではないので）、
正規化しておくのがDB設計のセオリーなのでそのほうが良いかと思いました😌
There was a problem hiding this comment.
（あ、 #278 があったんですね。コメントする場所間違えちゃいましたかね😅）
| @@ -0,0 +1,17 @@ | |||
| class CreateRecentlyEvents < ActiveRecord::Migration[5.1] | |||
| def change | |||
| create_table :recently_events do |t| | |||
There was a problem hiding this comment.
recentlyって「過去」なイメージなのですがどうでしょうか？
「（近い）未来」を意味する単語の方が良かったりしますかね？
/cc @yasulab
There was a problem hiding this comment.
recently だと確かに過去だったので fuature でやってみようかなと思います
テーブルの正規化を行う為に、dojo_idなどの非正規部分を削除した coderdojo-japan#277 (review)
|
schemeの非正規化部分を削除しました。問題なければ一旦mergeして頂いてmodelを作成,各taskの作成と行きたいと思います(同一PRでやる方が良い…?) |
|
一旦名前変更が入るのでcloseして新しいbranchで作業したいと思います! |
背景
/eventsの追加 #270 でeventsを作るに辺り直近のイベント情報が欲しい行ったこと
be rails g migration CreateRecentlyEvents dojo_id:integer dojo_name:string service_name:string service_group_id:string event_id:string event_url:string evented_ad:datetime