-
-
Notifications
You must be signed in to change notification settings - Fork 108
Upserting dojo_event_services
table
#140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ref #139 (forked repoからはCIが回らないのを忘れていたのでPRを作り直しました) |
|
||
list = YAML.load_file(Rails.root.join('db','dojo_event_services.yaml')) | ||
list.each do |des| | ||
unless DojoEventService.names.keys.include?(des['name']) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
DojoEventService.names
で定義されているイベントサイトを使っていなければスキップする
lib/tasks/dojo_event_services.rake
Outdated
end | ||
|
||
dojo = Dojo.find_by(name: des['dojo_name']) | ||
unless dojo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dojos
テーブルからレコードが引けなければスキップする
dojo_event_services
table
dojo_event_services
tabledojo_event_services
table
実行結果はこんな感じです。
|
レビューお願いします!😊 |
運用について補足しておくと、 |
なお、現状では |
MEMO: 先にこちらの Issue を対応すると楽そう |
あ、1点だけ確認したいんですが、 |
コミットログ見た感じだと次のコミットが最近追加された道場なので、1週間以上Rakeタスクを実行していない場合は対応する必要がありそうですね 🆕 ✨ 2017-10-22 f22c70e Yohei Yasukawa Add CoderDojo 松戸 🆕 |
テーブルを作った当時はそういう認識でした。 「複雑になるから」という点についてはdojoごとの運用に依存すると思っていて、 なので、このhas_manyに対応するかどうかについては、メリデメを整理して運用方針を決めのとともに対応するかどうかを決めるのが良いのかなーと考えています😌 |
認識合わせありがとうございます! 😸 状況の認識、把握しました 🙆
なるほどですね🤔 いただいた状況を僕なりに解釈すると、現状では次のような認識をしています💭
現状では上記のような認識で、 🤔.oO(一方で「今やるか後でやるか」はまた別の話かなとも考えています) |
これ、厳密にやろうとするとするほど運用ルールが増えてしまうか、 例えば、Bで行く場合は「再集計させなくしてしまう」とかですね。
はい、そうですね、ここも優先度に加味して決めたいです。 |
@nalabjp あー、ごめんなさい! 💦 肝心な結論で typo してました...orz
混乱させてしまってすみません 🙏 💦 |
A案の方でしたか、どちらとも読める感じを受けつつも、そのまま解釈してみました😅 A案はそうですね、
これがネックなので運用でカバーしつつ、コードに落とせるところは落としていくっていう感じでしょうかね。 運用を始める前にhas_many対応までやってしまうのであれば、 |
見逃していた移行前のイベントサービスが見つかり次第、随時追加していくっていう運用を考えているのですが、いかがですかね? 「あ、ここのDojoのイベントサービスの集計を忘れてた」といった時に随時追加していく形を想定しています。
ちなみに僕としては Issue としてメモしつつ、今やるとキリがなさそうなので「後でやる」というイメージを持っています。設計としては事前に |
なるほど、最小コストで運用を始めたいって感じでしょうか。 |
TODO
|
e7bb05d
to
6c5f72f
Compare
6c5f72f
to
d195135
Compare
こちら、一旦ヤメました。 それ以外のTODOは完了しました。 |
確認しました! ✅ 後回しにしたものは一旦 Issue に書き出しておいたので、こちらの PR はマージしますね! ありがとうございます 😸 |
#12
#128 で作成した集計のrake taskを使うためにdojo_event_servicesテーブルのためのデータをyamlとして作成しました。
TODO