Yohei Yasukawa

必要そうなデータ構造として Event モデルの案を description に書き出しました 📝

🤔.oO(もしやるとしたら、Doorkeeper / connpass / Facebook Event の実装を参考にしながらやる形になりそう)

@nalabjp > 既に作成済みのDBに対して$ dojos:update_db_by_yamlを実行しているという状況でしょうか？ ですね! 本番環境のDBを `$ heroku pg:pull DATABASE_URL coderdojo_jp_development --app coderdojo-japan` で取得してから実行しています! 📥 ☁️

> `SELECT setval('dojos_id_seq', coalesce((SELECT MAX(id)+1 FROM dojos), 1), false);` あー、なるほど! ではこちらをタスク内に実装すれば解決できそうですね...!! 早速のコメントありがとうございます! 😍

おー！あると紐付け作業が捗りそうです...!! (＞人＜ )✨

> 実態との乖離 @nalabjp というと、具体的には、例えば「Zen または coderdojo.jp 内の Dojo ID が変わってしまう場合」というケースへの対処策、みたいな感じですかね? 🤔💭

個人的には yaml で対応するのは (主に対応している僕が) 辛くなりそうだなーという感じで、少なくとも現状の体制のままであれば運用の負担を上げたくないな、という気持ちはあります >< 💦

(タスクを僕から剥がして他の人に移譲していけば良い、というのはあるかなと思います。その場合は移譲してから、移譲後の対応速度や負担などを鑑みて再度検討したいなという気持ちです)

> 主催が変わって開催場所(?)も違うところになったけどその情報をZenで更新するのを忘れた、とかですね。 @nalabjp なるほどなるほど。 下記の事例では Zen は現在地情報から Dojo id を探すときにしか使われず、coderdojo.jp 側も[イベントのURL情報しか保有して提供していない](https://coderdojo.jp/events.json)ため、開催場所を知るためには対応先の API (Doorkeeper API / connpass API など) も使う必要があるため大丈夫そうですが、coderdojo.jp 側で頑張って場所データのキャッシュなどまで持たせない方がいい、みたいな認識で合ってますかね? 🤔💭  ## 参考: https://coderdojo.jp/events.json のデータ例 

@togazo ありがとうございます! まだ見通しは立ってないですが、紐付け作業をする際は活用させていただきますね 😉 ✨