Re: Pluggable Storage Engine化について (Tritonn-dev 52) - Tritonn

こんにちは。池田です。

浅倉さんレスありがとうございます。

SHOW ENGINE案は良いですね。pluggable storage engineに対しても上手く使えるのかどうか
調べて見たいと思います。

Pluggableにすると、SQLエンジン部分とは切り離した開発ができるようになります。
先ほどのメールに書いたように、MySQLの拡張という立場からすると制限もいくつか
でてきますが、単にインストールや配布がしやすくなるというメリットだけでなく、
開発・テスト・品質保証という点でも分離できるメリットも大きいと感じています。

明日、いろいろBrianに相談してみるつもりです。

07/12/05 に asaku****@weakp*****<asaku****@weakp*****> さんは書きました:
> 　どうも、浅倉です。
>
> > 【SHOW SENNA STATUSコマンド】
> > parserを改造しているので、Pluggable Storage Engineでは実現困難。
>
> 　こちらですが、SHOW ENGINEでは対応できないのでしょうか。
> innodb等のstatusもこちらで参照するようになっていたので、engine関連の
> statusはこちらで参照できるように変わったのかな、とか思っていたもので。
>
>
> > 【USING句以下の拡張定義情報】
> > parserを改造しているので、Pluggable Storage Engineでは実現困難。
>
> 　WITH PARSERはおそらく使えませんよね。。。
>
> USINGで指定できるindex typeはengineによって違うのだから、ある程度自由
> に渡せるようになっていても良いように思うのですけれど。
>
> > 【KWIC関数】
> > native SQL関数として実装しているので、Pluggable Storage Engineでは実現
> > 困難。
> > ここは悩ましいところです。以前のUDFに戻るとか？
>
> 　これはUDFにするしかないのかも。。。
>
>
> ざっと読んで気付いた点はこんな感じです。
>
> PluggableになるメリットはMySQLのバージョンに合わせる必要がなくなる（気
> がする）ってことと、rpmとかでの配布・導入がしやすくなる（気がする）こと
> でしょうか。
> 個人的には導入が楽になるメリットは大きい、と思ってます。
>
>
> > 【Fulltext関連機能強化】
> > 2ind機能など、MySQL本体によるFulltextインデックスの扱いが
> > 弱い部分について。
>
> についてはMySQL本体側のポリシーがどうなっているのかによりますよね。。
> Sennaだけのメリットではないですので、MySQL側に取り込まれるといいのに、
> と思いますけれど。
>
>
> --
> 浅倉卓司
>
> _______________________________________________
> Tritonn-dev mailing list
> Trito****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/tritonn-dev
>

Tritonn

[Tritonn-dev 52] Re: Pluggable Storage Engine化について