datasourceレベルでTime field nameを指定しているものをクエリービルダーの設定に持ってこれないか

[kou]

テーブルごとにTime fieldが変わることがあるから。

[kou]

@kfurueda-amiya 実装を見ていないんですが、datasourceレベルで指定するのが適切っぽいんでしょうか！？

[kfurueda-amiya]

@kou この仕様はElasticSearchを参考に決めた経緯があります。 しかしながら、ご指摘の通り、テーブルごとにTimeFieldが変わることはありえますね。

[kou]

@kfurueda-amiya なるほど！ Elasticsearchのデータソースの設定画面をチラ見してみたのですが、Elasticsearchのデータソースはインデックス（Groongaでいうテーブル）ごとにデータソースを作る設計みたいなのでデータソースの設定にTime fieldがあるみたいです。

Elasticsearchのデータソースみたいにテーブルごとにデータソースを作ってね、というのと、データソースは1つで、クエリービルダーでテーブルを指定できるのだとどっちが使い勝手がよさそうですか！？個人的には（Elasticsearchのデータソースとは違って）データソース1つで、クエリービルダーでそれぞれテーブルを指定できる方が便利そうな気がしました。（データソースを1回設定すれば共有できるから。）

[kfurueda-amiya]

@kou 一長一短かとは思います。 当初、このプラグインを開発する際に、特定のテーブルの情報を様々な方法で可視化するというところから始まったため、 毎回TimeFieldを指定するのが面倒にならないように、ConfigEditorでの指定のまま残していました。 とはいえ、QueryEditorで指定できるようにする方が、より汎用性が増すと思います。

上記の仕様変更の実装について、本日の夕方くらいから稼働が取れると思いますが、スケジュール的に間に合いますか？

[kou]

なるほど！ どういうコンセプトで開発を進めるのが適切かということですね！

特定のテーブルの情報を様々な方法で可視化する

というコンセプトもアリだと思います！その場合はTime fieldだけではなくテーブル名もデータソースで指定できた方がよいと思います！

ちなみに、当初は「特定のテーブルの情報を様々な方法で可視化する」というコンセプトだったということですが、少し使ってみた感触としては、当初のコンセプト通りの設計で進めたほうがよさそうな感触ですか？それとも、それよりも汎用性を増す方向の方がよさそうな気がしますか！？

私は「特定のテーブルの情報を様々な方法で可視化する」というコンセプトだったことを知らなかったので、汎用性を増す方向の方がよいかと思っていましたが、データソース作成時にテーブルも指定するなら「特定のテーブルの情報を様々な方法で可視化する」方向でもアリだと思うようになりました。

スケジュールは大丈夫です！

[kfurueda-amiya]

@kou 特定テーブルありきのコンセプトで進めていましたが、 結果的に、テーブルごとにではなく、TimeFieldごとにdatasourceを指定するというものとなっているため、使い方がわかりにくいものとなっていますね。 TimeFieldが変わらない場合には指定が減るため便利ではありますが、 そうでない場合は、TimeFieldの数だけdatasourceを作って回避しなくてはならないという状況です。

そのため、ConfigEditorでは、デフォルトのテーブル名とTimeFieldを指定させるものとして、 QueryEditorでオーバーライドしてもよい(指定なしであればデフォルト値使用)というのが、 どちらのコンセプトも拾えて、一番有用となるかと思います。

[kou]

なるほど！データソースの画面では「Time field name」ではなく「Default time field name」と「Default table name」をしてできるようにするということですね！ ではそうしましょう！

[kfurueda-amiya]

上記の内容を反映いたしました。 具体的には以下の変更となります。 ・Config Editorで、Time field、Tableのデフォルト値を指定するカラムを追加(time fieldは文言変更) ・Query EditorにTime fieldを追加 ・Query EditorでTable Name・Time fieldが省略された場合は、デフォルト値が使用される

[kou]

さすがです！