Skip to content

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

Merged
merged 8 commits into from
Oct 31, 2017
Merged

Conversation

nalabjp
Copy link
Member

@nalabjp nalabjp commented Sep 27, 2017

#12

#128 で作成した集計のrake taskを使うためにdojo_event_servicesテーブルのためのデータをyamlとして作成しました。

TODO

  • dojo_event_serviceテーブルに流し込むrake taskを作成する

@nalabjp
Copy link
Member Author

nalabjp commented Sep 27, 2017

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'])
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DojoEventService.namesで定義されているイベントサイトを使っていなければスキップする

end

dojo = Dojo.find_by(name: des['dojo_name'])
unless dojo
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dojosテーブルからレコードが引けなければスキップする

@nalabjp nalabjp changed the title [WIP] Dojo event services data Upsertig dojo_event_services table Sep 27, 2017
@nalabjp nalabjp changed the title Upsertig dojo_event_services table Upserting dojo_event_services table Sep 27, 2017
@nalabjp
Copy link
Member Author

nalabjp commented Sep 27, 2017

実行結果はこんな感じです。

$ bin/rake dojo_event_services:upsert
Task as `dojo_event_services:upsert` starting...

Skipped: 52
  恵庭 (北海道): Not used `connpass` or `doorkeeper`
  滝沢 (東北): Not used `connpass` or `doorkeeper`
 ...
(略)
 ...
  宜野湾 (沖縄): Not used `connpass` or `doorkeeper`
  宮古島 (沖縄): Not used `connpass` or `doorkeeper`
Inserted: 49
  札幌 (北海道): {"dojo_id"=>[nil, 1], "name"=>[nil, "connpass"], "url"=>[nil, "https://coderdojo-sapporo.connpass.com"], "group_id"=>[nil, 3316]}
  札幌東 (北海道): {"dojo_id"=>[nil, 2], "name"=>[nil, "connpass"], "url"=>[nil, "https://coderdojo-sapporo-east.connpass.com"], "group_id"=>[nil, 3594]}
 ...
(略)
 ...
  那覇 (沖縄): {"dojo_id"=>[nil, 99], "name"=>[nil, "doorkeeper"], "url"=>[nil, "https://coderdojookinawa.doorkeeper.jp/"], "group_id"=>[nil, 9188]}
  嘉手納 (沖縄): {"dojo_id"=>[nil, 101], "name"=>[nil, "connpass"], "url"=>[nil, "https://coderdojo-kadena.connpass.com/"], "group_id"=>[nil, 3332]}
Kept: 0
Updated: 0
$ bin/rake dojo_event_services:upsert
Task as `dojo_event_services:upsert` starting...

Skipped: 52
  恵庭 (北海道): Not used `connpass` or `doorkeeper`
  滝沢 (東北): Not used `connpass` or `doorkeeper`
 ...
(略)
 ...
  宜野湾 (沖縄): Not used `connpass` or `doorkeeper`
  宮古島 (沖縄): Not used `connpass` or `doorkeeper`
Kept: 49
  札幌 (北海道)
  札幌東 (北海道)
 ...
(略)
 ...
  那覇 (沖縄)
  嘉手納 (沖縄)
Updated: 0
Inserted: 0

@nalabjp
Copy link
Member Author

nalabjp commented Sep 27, 2017

レビューお願いします!😊

@nalabjp
Copy link
Member Author

nalabjp commented Sep 27, 2017

運用について補足しておくと、db/dojo_event_services.yamlは管理者が手動更新して、必要があればこのPRのrake taskを実行するイメージです📝

@nalabjp
Copy link
Member Author

nalabjp commented Sep 27, 2017

なお、現状ではdojo has_one dojo_event_serviceなので、「connpassからdoorkeeperへ移行した」みたいなケースの過去分をケアすることができない仕様になっています。
(全てを把握しているわけではないですが、そういうケースがあったのは確認しました)

@yasulab
Copy link
Member

yasulab commented Oct 16, 2017

MEMO: 先にこちらの Issue を対応すると楽そう
#154

@yasulab
Copy link
Member

yasulab commented Oct 29, 2017

MEMO: 先にこちらの Issue を対応すると楽そう
#154

@nalabjp こちら対応できていると思うので、このPRをマージしちゃおうかなと考えていますが、何かやり残したことってありましたっけ? 🤔💭

@nalabjp
Copy link
Member Author

nalabjp commented Oct 29, 2017

@yasulab

何かやり残したこと

新しいdojoができているのかなー?と思っているのと、
#164 のためのfacebookのgroup idを登録することができていないので、
#164 を見越してそこまでやってしまったほうがちょっとだけ楽そうな気がしています。
(作業量は大して変わらないけど、新たに差分更新のPRを作る必要があります。)

@yasulab
Copy link
Member

yasulab commented Oct 29, 2017

状ではdojo has_one dojo_event_serviceなので、「connpassからdoorkeeperへ移行した」みたいなケースの過去分をケアすることができない仕様
全てを把握しているわけではないですが、そういうケースがあった

あ、1点だけ確認したいんですが、 dojo has_many dojo_event_services にしなかった理由は「複雑になるから」という認識で大丈夫ですかね? >< 💦 (あまりよくあるケースではないと思いますが、確かに移行したケースはいくつかあったので)

@yasulab
Copy link
Member

yasulab commented Oct 29, 2017

新しいdojoができているのかなー?と思っている

コミットログ見た感じだと次のコミットが最近追加された道場なので、1週間以上Rakeタスクを実行していない場合は対応する必要がありそうですね 🆕 ✨

2017-10-22 f22c70e Yohei Yasukawa Add CoderDojo 松戸 🆕

@yasulab
Copy link
Member

yasulab commented Oct 29, 2017

#164 のためのfacebookのgroup idを登録することができていないので、
#164 を見越してそこまでやってしまったほうがちょっとだけ楽そう

お、了解です! 🙆 ではマージは一旦やめておきますね ;)

@nalabjp
Copy link
Member Author

nalabjp commented Oct 29, 2017

dojo has_many dojo_event_services にしなかった理由は「複雑になるから」という認識で大丈夫ですかね?

テーブルを作った当時はそういう認識でした。
その後、移行したケースがいくつかあるのを確認し、実際に集計を動かしてみると多少影響のありそうな数値だというのがわかったのでhas_manyにするという方法もアリかもしれないなー、と思うようになりました。
現状では対応可能だけどまだやっていない、ぐらいの認識でいます。
(移行したケースの洗い出しを全てのdojoに対して調べ直さないといけない、というのもあり😅)

「複雑になるから」という点についてはdojoごとの運用に依存すると思っていて、
たとえば、複数のイベントサイトで募集している場合は重複して計上されてしまったりする、とかがパッと思いつくところでしょうか。(これは機械的に弾くルールをdojoごとに作る必要が出てきそうですね)
逆にhas_manyにしないことによるデメリットも存在していて、
たとえばconnpassからdoorkeeperに移行したとしてconnpassで集計した期間を集計しなおそうとすると、
実装済みのRake taskの仕様上doorkeeperに移ってしまったあとでは再集計することができずレコードが消えてしまう、
といったケースが想定できます。

なので、このhas_manyに対応するかどうかについては、メリデメを整理して運用方針を決めのとともに対応するかどうかを決めるのが良いのかなーと考えています😌

@yasulab
Copy link
Member

yasulab commented Oct 29, 2017

現状では対応可能だけどまだやっていない、ぐらいの認識でいます。

認識合わせありがとうございます! 😸 状況の認識、把握しました 🙆

なので、このhas_manyに対応するかどうかについては、メリデメを整理して運用方針を決めのとともに対応するかどうかを決めるのが良いのかなーと考えています😌

なるほどですね🤔 いただいた状況を僕なりに解釈すると、現状では次のような認識をしています💭

  • A. dojo has_many dojo_event_services
    • 「複数のイベントサイトで募集している場合は重複して計上」というデメリットは、どのイベントサービスをDBに登録するかで防げそう ✅
    • また、ご指摘のようにあとで機械的に弾くことも簡単そう ✅
    • Doorkeeper 有料化で connpass に移行した Dojo が複数あることは既に確認しています 💦
  • B. dojo has_one dojo_event_service:
    • 「再集計することができずレコードが消えてしまう」というデメリットは、解消するのが困難そう 💦
    • 今後移行するDojoがあるたびに上記の問題を解決するのは骨が折れそう💦

現状では上記のような認識で、 方向性としては「B. dojo has_one dojo_event_service」の方が良さそうかなと考えています。 方向性としては「A. dojo has_many dojo_event_services」の方が良さそうかなと考えています。

🤔.oO(一方で「今やるか後でやるか」はまた別の話かなとも考えています)

@nalabjp
Copy link
Member Author

nalabjp commented Oct 29, 2017

これ、厳密にやろうとするとするほど運用ルールが増えてしまうか、
dojoごとの特殊ロジックが必要になってくる感じなので、
優先したいことを決めた上でその時点でのデメリットを排除するのが幸せそうですねぇ。

例えば、Bで行く場合は「再集計させなくしてしまう」とかですね。

  • 現状は冪等性担保のために最集計時は当該期間のレコードを削除している
  • これを当該期間にレコードがある場合は集計済みとして再集計できなくする(手動でレコードを消す等温かみのある運用をする)

一方で「今やるか後でやるか」はまた別の話

はい、そうですね、ここも優先度に加味して決めたいです。

@yasulab
Copy link
Member

yasulab commented Oct 29, 2017

@nalabjp あー、ごめんなさい! 💦 肝心な結論で typo してました...orz

方向性としては「B. dojo has_one dojo_event_service」の方が良さそうかなと考えています。 方向性としては「A. dojo has_many dojo_event_services」の方が良さそうかなと考えています。

混乱させてしまってすみません 🙏 💦

@nalabjp
Copy link
Member Author

nalabjp commented Oct 29, 2017

A案の方でしたか、どちらとも読める感じを受けつつも、そのまま解釈してみました😅

A案はそうですね、

厳密にやろうとするとするほど運用ルールが増えてしまうか、
dojoごとの特殊ロジックが必要になってくる感じ

これがネックなので運用でカバーしつつ、コードに落とせるところは落としていくっていう感じでしょうかね。

運用を始める前にhas_many対応までやってしまうのであれば、
移行した過去のあるdojoの洗い出しをやってしまうというのがタスクとして追加される感じですね。
コードの修正は些細なものかと思います😌

@yasulab
Copy link
Member

yasulab commented Oct 29, 2017

移行した過去のあるdojoの洗い出しをやってしまうというのがタスクとして追加される

見逃していた移行前のイベントサービスが見つかり次第、随時追加していくっていう運用を考えているのですが、いかがですかね? 「あ、ここのDojoのイベントサービスの集計を忘れてた」といった時に随時追加していく形を想定しています。

一方で「今やるか後でやるか」はまた別の話

ちなみに僕としては Issue としてメモしつつ、今やるとキリがなさそうなので「後でやる」というイメージを持っています。設計としては事前に has_many に変更しておいて、いつでも移行前のイベントサービスを追加できる体制にしつつ、実際の追加はゆっくり進めていく (今はやらない) という感じですね 🤔

@nalabjp
Copy link
Member Author

nalabjp commented Oct 29, 2017

なるほど、最小コストで運用を始めたいって感じでしょうか。
良いと思います👍
それでいきましょう。

@nalabjp
Copy link
Member Author

nalabjp commented Oct 29, 2017

TODO

@nalabjp nalabjp force-pushed the dojo-event-services-data branch from e7bb05d to 6c5f72f Compare October 30, 2017 17:52
@nalabjp nalabjp force-pushed the dojo-event-services-data branch from 6c5f72f to d195135 Compare October 30, 2017 17:56
@nalabjp
Copy link
Member Author

nalabjp commented Oct 30, 2017

Dojo has_one DojoEventServiceをhas_manyに変更する

こちら、一旦ヤメました。
rake taskをちょっと直さないと動かなくなってしまうので、運用し始めてからの対応にしたいです。

それ以外のTODOは完了しました。

@yasulab
Copy link
Member

yasulab commented Oct 31, 2017

確認しました! ✅ 後回しにしたものは一旦 Issue に書き出しておいたので、こちらの PR はマージしますね! ありがとうございます 😸
cf. #168

@yasulab yasulab merged commit 3a8e492 into master Oct 31, 2017
@yasulab yasulab deleted the dojo-event-services-data branch October 31, 2017 01:48
@yasulab yasulab added the 統計情報 Tracking event record function via APIs: https://coderdojo.jp/stats label Jan 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
統計情報 Tracking event record function via APIs: https://coderdojo.jp/stats
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants