Takahiro INAGAKI

@losywee Is this what you want to do? ```golang var user3 User2 user3.ID = 1 codes := []string{"EN", "CN"} var langs []Language res2 := db.Debug().Model(&user3).Where("code IN ?", codes).Association("Languages").Find(&langs) ``` ```...

V0はトラコンで使用したときのものでmasterは新しく開発しようとした残骸です。

そうです。 masterは未完成ですので、動くものだとv0を利用するのが良いと思います。 ただ、リソース数が多くなるとagentのロジックとAPIコールの頻度が多くなりDB書き込みのロック待ちが発生してリクエストがTimeoutしてしまうという問題が当時あったので色々と改修したほうがよいと思います。 以下計測したわけじゃないので全て憶測で書いてます。 - 確か、一気にデプロイすると更新が大量に発生してDBがロックされて待ちの間にTimeoutという感じだったので、デプロイを小分けにして対応したような気もする - Timeoutに関しては暫定でTimeoutするまでの時間を延ばすと一時しのぎはできるかも - DB書き込みのロック待ち - LevelDBを使ったstoreの実装がよろしくない - LevelDBでTransactionしているのにRWMutexでLockしていたり - シリアライズにJSONを利用している - https://github.com/ophum/humstack/blob/v0/pkg/store/leveldb/store.go - NoSQL(Storeインターフェース)やめてGormとかでRDBMSに対してSQLを直接叩いたほうが効率は良くなると思う - APIコールの頻度 - なんか色々改善しようとした形跡はあるけど、あまり意味はなかったと思われる --- 個人的には最初から設計・実装するか、k8sのエコシステムを利用して、VMやネットワーク、Diskなどの部分を操作するものを自作するなどのほうがいいんじゃないかと思います。