ささいなことですが。

Windowsアプリテスト自動化ライブラリFriendly開発者の日記です。

Windowsアプリテスト自動化でのキーエミュレートはありなのか?

最近お客様から「Friendlyではキー操作は使えないの?」って聞かれることが何回かありました。キーエミュレートねー。Friendly作る前はやってたけど不安定だったんですよねー。MSDNにもタイミング問題あるって書いてるし。でもFriendlyと組み合わせたらなんとかなるんじゃないか?ってことで色々考えてみました。
なお、このエントリを書くにあたりとっちゃんさんから色々教えていただきました。ありがとうございました!

結論から言うとアリ

タイミング依存の失敗はあると言われています。が、今回考えてみるとテストというコンテキストではFriendlyを使うことによってタイミングをコントロールしきれると思います。
で、コード書いてみました。もしかするとライブラリに組み込むかもしれませんが、ちょっと先になるので必要な方はコピって使ってください。DLLインジェクションやってますので定義するDLLの.Netのバージョンは対象のアプリのもの以下でお願いします。対象がネイティブアプリならバージョンは何でもOKです。

WinForms

using Codeer.Friendly;
using Codeer.Friendly.Dynamic;
using Codeer.Friendly.Windows;
using System.Windows.Forms;

namespace SendKeyEx
{
    public static class WinFormsImplement
    {
        public static void FormsSendKeys(this WindowsAppFriend app, string keys)
            => app.Type<SendKeys>().SendWait(keys);

        public static void FormsSendKeys(this WindowsAppFriend app, string keys, Async async)
        {
            Initializer.Init(app);
            app.Type<SendKeys>().SendWait(keys, async);
            TimerMessageWaiter.Wait(app);
        }
    }
}

WPF

using Codeer.Friendly;
using Codeer.Friendly.Dynamic;
using Codeer.Friendly.Windows;
using System.Threading;
using System.Threading.Tasks;
using System.Windows.Threading;

namespace SendKeyEx
{
    public static class WPFImplement
    {
        public static void WPFSendKeys(this WindowsAppFriend app, string keys)
        {
            Initializer.Init(app);
            app.Type(typeof(WPFSendKey)).SendWait(keys);
        }

        public static void WPFSendKeys(this WindowsAppFriend app, string keys, Async async)
        {
            Initializer.Init(app);
            app.Type(typeof(WPFSendKey)).SendWait(keys, async);
            TimerMessageWaiter.Wait(app);
        }
        
        static void SendWait(string keys)
        {
            //キー送信
            bool sent = false;
            Task.Factory.StartNew(() => 
            {
                System.Windows.Forms.SendKeys.SendWait(keys);
                sent = true;
            });

            //送信が完了するのを待つ
            while (!sent) Thread.Sleep(0);

            //キー処理
            DoEvents();
        }

        static void DoEvents()
        {
            DispatcherFrame frame = new DispatcherFrame();
            Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background,
                new DispatcherOperationCallback(ExitFrames), frame);
            Dispatcher.PushFrame(frame);
        }

        static object ExitFrames(object f)
        {
            ((DispatcherFrame)f).Continue = false;
            return null;
        }
    }
}

Native

using Codeer.Friendly.Windows;

namespace SendKeyEx
{
    public static class NativeImplement
    {
        public static void SendKeys(this WindowsAppFriend app, string keys)
        {
            Initializer.Init(app);
            System.Windows.Forms.SendKeys.SendWait(keys);
            TimerMessageWaiter.Wait(app);
        }
    }
}

共通で使うコード

using Codeer.Friendly.Windows;

namespace SendKeyEx
{
    static class Initializer
    {
        internal static void Init(WindowsAppFriend app)
        {
            var asm = typeof(Initializer).Assembly;
            object isInit;
            if (app.TryGetAppControlInfo(asm.FullName, out isInit)) return;

            WindowsAppExpander.LoadAssembly(app, asm);
            app.AddAppControlInfo(asm.FullName, true);
        }
    }
}
using System.Windows.Forms;
using Codeer.Friendly.Windows;
using Codeer.Friendly.Dynamic;

namespace SendKeyEx
{
    class TimerMessageWaiter
    {
        public bool Arrived { get; set; }
        public TimerMessageWaiter()
        {
            var timer = new Timer { Interval = 1 };
            timer.Tick += (_, __) =>
            {
                timer.Stop();
                Arrived = true;
            };
            timer.Start();
        }

        internal static void Wait(WindowsAppFriend app)
        {
            var waiter = app.Type<TimerMessageWaiter>()();
            while (!(bool)waiter.Arrived) System.Threading.Thread.Sleep(0);
        }
    }
}

そもそものSendKeysの動作

この辺参考に
About Messages and Message Queues (Windows)
GetMessage 関数
Reference Source

SendInput実行からUIスレッドで実行するまでの流れはこんな感じです。

  1. SendInput関数実行によりキーボードストリームに入力データが入る(MSDN
  2. 割り込み処理により(※注)アクティブなUIスレッドのシステムメッセージキューに入力メッセージを配置(MSDN
  3. UIスレッドがそれを取り出し、変換しながら、さらに自分のスレッドにメッセージをポストしながら実行

※注の部分に関しては正規のドキュメントは未発見ですが、以下の理由から割り込みで実行されると考えています。なぜそれにこだわっているかというと、ここでやっている同期の取り方はSendKeysを呼び終わった段階でアクティブなUIスレッドのシステムメッセージキューに入力メッセージが届いているという考えに依存してるからです。

  • もともとの処理がドライバで行われている。キードライバの場合はIRQ割り込み。
  • とっちゃん談
  • SendKeysに大量に文字列を渡したときに重い(単にバッファに入れるだけならもっと早いはず)
  • そうでなければ.NetのSendKeysの実装が説明つかない(どう見てもこの考えに依存した実装になっている)

SendKeysが失敗する理由

これを踏まえて、SendKeysが目的のキー処理を失敗する理由を考えます
①キーボードの種類や言語によって失敗する可能性がある
②対象のアプリがアクティブでない
③対象のコントロールにフォーカスが当たっていない
④UIスレッドのシステムキューのバッファ、およびアプリ部分の何かのバッファが溢れた
⑤野良メッセージループが回っている

加えて、テストという観点で考えると
⑥同期がとれていないので結果取得のタイミングで処理が終わっていない可能性がある

①はまあ仕方がない。制限事項として受け入れるしかないですね。Friendlyなどの別の操作ライブラリと合わせて使うことにより、その制限の範囲内でも十分な成果は上がられると思います。(しかもこれは失敗するときは絶対失敗するしタイミング依存の失敗にはならない)②③はFriendlyを使うと容易に解決できます。④⑤⑥ですがこれは同期が取れれば全部解決できそうです。⑤に関しては最後に別途解説します。④に関しては同期がとれればあふれるほどは送信しないですよね?同期が取れてもあふれるならそれはタイミング依存の失敗ではなく、送信データが悪いということで毎回失敗するはずです。

同期をとる

SendKeysにはSendWaitというものがあります。しかし、Vista以降ではUACの制限があり別プロセスがキーを受け取る場合、その終了を待つことができないようになっています。
SendKeys.SendWait メソッド (String) (System.Windows.Forms)
以前はジャーナルフックという手法を使っていて、別プロセスでもキーが送信されたことを確認できていたようです。コードを見ると努力の跡が見られます。
Reference Source
結局現在では、このSendWaitで待てるのはWinFormsでアクティブなUIスレッドで実行した場合のみです。今回はFriendlyを使って同期をとるコードを考えてみました。

WinForms

相手プロセスでSendKeysを実行するだけでOKです。処理が終わるまで待ってくれます。Asyncバージョンには最後に怪しい処理が入っています。Nativeの解説のところで解説します。

WPF

SendKeys.SendWait メソッド (String) (System.Windows.Forms)の待ち処理を見ると単にDoEvents()しているだけですね。これをWPF用に取り換えてやります。それで自分のスレッドへの投げ込みが上手く行かないので投げ込みは別スレッドからやってやります。WPFではSendKeysではなくInputManagerを使うのが良いとも言われてますのでそれで作ってもよいですが、SendKeysの方が圧倒的に使い勝手が良いので私はこれで実装しました。
で、そもそもの問題としてSendInput送って、その後メッセージ処理の前にUIスレッドのキューにそれが入っていることが保証されているの?という話ですが、そこは※注で書いている話です。オリジナルのSendKeysがそうやってるんだから多分この考えはあっていると思います。正式なドキュメント見つけたい・・・。

Native

今回作ったネイティブ版の実装は実は上の二つ(WinForm版、WPF版)とは待ちが終了するタイミングが異なります。上の二つが処理が完全に終わる(キーイベントを受けて実行する関数を抜ける)のを待ち切るのに対して、こちらはTimerメッセージが通るくらいメッセージ処理に余裕ができれば抜けます。具体例としてショートカットキーを実行した後モーダルダイアログが出る場合、WinForms版とWPF版はダイアログが閉じるまで固まっています。そのためAsync版があります。対してネイティブ版はダイアログが出てメッセージループが回り始めれば抜けます。とは言えどちらも入力キーの処理が残っていれば制御は返しませんし、ダイアログが出たら抜けてくれるならこっちの方が使い勝手いいんじゃないの?って思うかもしれません。多くの場合はその通りでこれで問題なく処理を進めることができます。後述しますが、欠点はキーイベントから呼び出された関数の中で独自ループを回している場合に同期が取りづらくなるというものです。
それでTimerメッセージ待ちってなんやねん!ということなんですが根拠はこちらのドキュメントです。
GetMessage 関数
Windowsのメッセージには処理される優先順位があります。

  1. 送信済みメッセージ
  2. ポスト済みメッセージ
  3. 入力(ハードウェア)メッセージとシステムの内部イベント
  4. 送信済みメッセージ(再度)
  5. WM_PAINT メッセージ
  6. WM_TIMER メッセージ

特にSendMessageは強力でGetMessageせずともSendMessageしている最中とか、いくつかのWin32APIを呼び出している最中に割り込んできたりします。ポストメッセージが入力よりもプライオリティが高いのですねー。入力メッセージを受けて自分に対してポストメッセージするからかな?それで、Timerメッセージは優先順位が一番低くなっています。つまり入力メッセージや、それから送られたポストメッセージがキューに残っているとメッセージが処理されません。このメッセージが到着した(タイマのTickが飛んできた)ということはその前に送ったキー処理はすべて終わっているといえます。それでWPFとWinFormsの非同期版にこれが入っている理由は、実はFriendlyの処理が内部的にSendMessageとPostMessageを使っているからです。ともに入力メッセージの処理よりプライオリティが高いんですね。普通にFriendlyの処理ばかりを使っていると非同期を使っても、後の処理が追い越すことはないのですが(もちろん前の処理中にダイアログなど表示されると別です)今回は入力メッセージが絡むので嫌な感じのところで前の処理に割り込むことがあります。それを防ぐためにここでも入力メッセージの処理の終了待ちをいれています。

⑤野良メッセージループが回って失敗する

思い返してみれば、タイミング依存の失敗のほとんどはこれじゃないかなー。簡単な例を書くと、ALT+Aでテキストボックスがあるダイアログを表示するアプリがあるとします。(入力結果はラベルに反映)
f:id:ishikawa-tatsuya:20170309144143p:plain

public partial class MainForm : Form
{
    public MainForm()
    {
        InitializeComponent();
    }

    void ButtonTextDialogClick(object sender, EventArgs e)
    {
        using (var dlg = new TextForm())
        {
            dlg.ShowDialog();
            _label.Text = _label.Text + dlg.InputText;
        }
    }
}
public partial class TextForm : Form
{
    public string InputText => _textBox.Text;
    
    public TextForm()
    {
        InitializeComponent();
    }

    protected override void OnClosing(CancelEventArgs e)
    {
        base.OnClosing(e);
    }
}

これにキーメッセージを送ります。

for (int i = 0; i < 2; i++)
{
    SendKeys.SendWait("%a");
    SendKeys.SendWait("abc");
    SendKeys.SendWait("{TAB}");
    SendKeys.SendWait("{ENTER}");
}

f:id:ishikawa-tatsuya:20170309144542p:plain
これは上手く行きます。ダイアログ起動→テキスト入力を二回繰り返してもキーの取りこぼしは発生しません。
しかし、以下のようにDoEventsを入れると途端に動作しなくなります。両方入れる必要はなく、どちらかでも失敗します。

public partial class TextForm : Form
{
    public string InputText => _textBox.Text;
    
    public TextForm()
    {
        InitializeComponent();
        Application.DoEvents();
    }

    protected override void OnClosing(CancelEventArgs e)
    {
        base.OnClosing(e);
        Application.DoEvents();
    }
}

このDoEventsで処理されると、どちらも期待のコントロールがまだ生成されてなかったり、Disable状態になってたりでキーが無視されてしまいます。
で、これは場合によればうまく行くこともあります。そのためSleepとかでなんちゃって対応される場合があり状況が悪化したりします。
これは極端な例ですが、DoEvents的メッセージ処理呼んでいる箇所はちょっと大きめのアプリならそれなりにありますよね。ましてやネイティブアプリなんてやりたい放題だし、WPFでもDispatcherFrameを使ったイベント処理もやるときはあるでしょう。(直接書いたつもりはなくても外部のGUIライブラリ使ったら内部的に使われてたとか)こういうコードは人間が操作する限りには問題は発生しません。むしろ体感をよくするために仕込まれたりします。

WinFormsとWPFのものはこれに対応できている

Friendlyは同期呼び出しなので、例えばイベント内でメッセージループを勝手に回したとしても、そのイベントが終わるまで待つので影響を受けません。モーダルダイアログを表示するときのみ非同期にしますが元々の処理の終了を待つことができるのとモーダルダイアログ起動待ちができるのとで野良メッセージループにハマらないように実装できます。もともとFriendlyの設計は、この野良メッセージループの対応を考えたものになっています(昔苦労したから
こんな感じで書きます。

using (var app = new WindowsAppFriend(process))
{
    var main = WindowControl.FromZTop(app);
    for (int i = 0; i < 2; i++)
    {
        var a = new Async();
        SendKeys.WPFSendKeys("%a", a);
        main.WaitForNextModal();
        SendKeys.WPFSendKeys("abc");
        SendKeys.WPFSendKeys("{TAB}");
        SendKeys.WPFSendKeys("{ENTER}");
        a.WaitForCompletion();
    }
}

同期なのに非同期にするんかい!なのですが、Friendlyではそういうものですw。
main.WaitForNextModal();で最初の野良ループはスキップできます。
最後の野良ループはa.WaitForCompletion();でスキップできます。ALT+Aで実行された関数の終了を完全に待つわけです。

ネイティブのSendKeysはここが弱い

今回のネイティブの実装ではこの問題は解決できていません。モーダルダイアログや野良ループがあったら待ち合わせは終了し、かつその関数が終わったことを確認するすべはありません。まあ、そこまでの同期は取れているので(キー処理が終わったことまでは確認できるので)アプリの設計をよく確認して他の手段で野良ループをよけるしかないですね。それにさんざん脅しましたが、全部が全部野良ループ回しているわけではないし、全体からするとやっぱり少数です。(どっちやねん

using (var app = new WindowsAppFriend(process))
{
    var main = WindowControl.FromZTop(app);
    for (int i = 0; i < 2; i++)
    {
        SendKeys.SendKeys("%a");
        var dlg = main.WaitForNextModal();
        SendKeys.SendKeys("abc");
        SendKeys.SendKeys("{TAB}");
        SendKeys.SendKeys("{ENTER}");
        //Enterの入力までは同期がとれている。
        //でもALT+Aが完全に終わったかはわからない
        //この場合だとモーダルダイアログの破棄を待つと同等のことができる
        //しかし、破棄後に野良ループを回すようなコードではそれを回避できない
        //別途そのアプリの特性を活かした待ち合わせを考える必要がある
        dlg.WaitForDestroy();
    }
}

実用可能ですが

より正確な操作手段があるならそちらを優先してつかうのが良いでしょう。あえてキーエミュレートをしたい場合や他に手段がない場合などにご利用ください。

LambdicSql - DBごとにパッケージを分けました

今までのLambdicSqlは、使いそうな句や関数を LambdicSql.Symbol ってことろに区別なく定義していました。なのでDBの種類によってはインテリセンスに出てくるけど使えない句とか結構あったんですよね・・・。まあSQLってそんなもんだし良いかなーって思ってたんですが、最近の方針転換で句や関数は可能な限り(できれば全部)定義しようということにしました。そうすると流石に全DB分同じところに定義するとカオスになってくるんですよね。

DBごとにパッケージを分けました。

で、素直に句と関数はDBごとに定義することにしました。共通で使えるものは共通化したいなーとも思ったんですが、逆にややこしくなるのでやめました。Selectとか一般的なやつも各DBごとにそれぞれ定義されています。

・基本部分。Expressionの解析とか。
LambdicSql

・DBごとの句や関数を定義。
LambdicSql.SqlServer
LambdicSql.Oracle
LambdicSql.MySql
LambdicSql.Npgsql
LambdicSql.SQLite
LambdicSql.DB2

例えば、SqlServerを使うときはこんな感じ

using LambdicSql;
using LambdicSql.SqlServer;
using static LambdicSql.SqlServer.Symbol;

....

//Top句はSqlServerのみ使える
static Sql<SelectData> Sample
  =>Db<DB>.Sql(db =>
        Select(Top(10), new SelectData
        {
            PaymentDate = db.tbl_remuneration.payment_date,
            Money = db.tbl_remuneration.money,
        }).
        From(db.tbl_remuneration));

書きやすさの向上

それぞれのDBで使えるものしかインテリセンスに出てこないので使いやすくなったと思います。うろ覚えの句とか書くときは特に。

すべてのSQLC#で表現する

分けることで、作る側としてもやりやすくなりました。後は、句と関数を追加していくだけです(多分
すべては言い過ぎですが可能な限り定義していきます。これ使うときってEFとかで書けないようなSQLを使いたいときだと思うので、マニアックなものでも対応していく方針です。

最近のLambdicSql - 空なら消える

Sqlを動的に作成する場合には、「空なら消えてくれればいいのに」があります。
LambdicSqlでは以下の場合には空を渡すと要素や句が消えます。

  • Select句のメンバ
  • Join
  • Where
  • Having
  • Order By

Select句のメンバ

//Typeを表示するときのみCase式を挿入する
var type = new Sql<string>();
if (isSelectType)
{
    type = Db<DB>.Sql(db =>
        Case().
            When(db.tbl_remuneration.money < 2000).Then("Cheap").
            When(db.tbl_remuneration.money < 3000).Then("Middle").
            Else("High").
        End());
}

var sql = Db<DB>.Sql(db =>
    Select(new SelectData
    {
        Name = db.tbl_staff.name,
        PaymentDate = db.tbl_remuneration.payment_date,
        Money = db.tbl_remuneration.money,
                    
        //タイプ
        Type = type
    }).
    From(db.tbl_remuneration).
        Join(db.tbl_staff, db.tbl_staff.id == db.tbl_remuneration.staff_id)
    );

isSelectTypeが有効のときは

SELECT
        tbl_staff.name AS Name,
        tbl_remuneration.payment_date AS PaymentDate,
        tbl_remuneration.money AS Money,
        CASE
                WHEN (tbl_remuneration.money) < (@p_0)
                THEN @p_1
                WHEN (tbl_remuneration.money) < (@p_2)
                THEN @p_3
                ELSE @p_4
        END AS Type
FROM tbl_remuneration
        JOIN tbl_staff ON (tbl_staff.id) = (tbl_remuneration.staff_id)

無効のとき、つまりtypeが空の時は消えます。

SELECT
        tbl_staff.name AS Name,
        tbl_remuneration.payment_date AS PaymentDate,
        tbl_remuneration.money AS Money
FROM tbl_remuneration
        JOIN tbl_staff ON (tbl_staff.id) = (tbl_remuneration.staff_id)

Where、Having

これらの句は条件を動的に組み立てるユーティリティもサポートしています。
Conditionクラスは第一引数がnullなら消えます。
両方消えると句自体がなくなります。

var minCondition = false;
var maxCondition = false;

var exp = Db<DB>.Sql(db =>
    new Condition(minCondition, 3000 < db.tbl_remuneration.money) &&
    new Condition(maxCondition, db.tbl_remuneration.money < 4000));

var query = Db<DB>.Sql(db =>
    Select(Asterisk()).
    From(db.tbl_remuneration).
    Where(exp)
);
SELECT *
FROM tbl_remuneration

Join、Order By

あまりないかもしれませんが、JoinとOrder Byも消えます。

var tbl_staff = new Sql<Staff>();
var asc = new Sql<OrderByElement>();
var desc = new Sql<OrderByElement>();
var sql = Db<DB>.Sql(db =>
    Select(new SelectedData2
    {
        Id = db.tbl_remuneration.staff_id
    }).
    From(db.tbl_remuneration).
    Join(tbl_staff, db.tbl_remuneration.staff_id == tbl_staff.Body.id).
    OrderBy(asc, desc));
SELECT
	tbl_remuneration.staff_id AS Id
FROM tbl_remuneration

こんな感じで楽にSQL構築ができます。

最近のLambdicSql - 自由度Up

github.com

組み合わせの自由度がアップしました。
Sqlビルダーという位置づけになった今、Sql構築の自由度は重要です。

+演算子のサポート

ちょっと前から生成したsql同士のサポートはありました。

var select = Db<DB>.Sql(db =>
    Select(new SelectData1
    {
        Name = db.tbl_staff.name,
        PaymentDate = db.tbl_remuneration.payment_date,
        Money = db.tbl_remuneration.money,
    }));

var from = Db<DB>.Sql(db =>
    From(db.tbl_remuneration).
    Join(db.tbl_staff, db.tbl_remuneration.staff_id == db.tbl_staff.id));

var where = Db<DB>.Sql(db =>
    Where(3000 < db.tbl_remuneration.money && db.tbl_remuneration.money < 4000));

var orderby = Db<DB>.Sql(db =>
    OrderBy(Asc(db.tbl_staff.name)));

//結合
var sql = select + from + where + orderby;

最近ではこれをLambda中で使うことができるようになりました。

var from = Db<DB>.Sql(db =>
        From(db.tbl_remuneration).
    Join(db.tbl_staff, db.tbl_remuneration.staff_id == db.tbl_staff.id));

//ラムダの中で結合
var sql = Db<DB>.Sql(db =>
    Select(new SelectData
    {
        Type = Case() +
                    When(db.tbl_remuneration.money < 2000).Then("Cheap") +
                    When(db.tbl_remuneration.money < 3000).Then("Middle") +
                    Else("High") +
                End()
    }) +
    from +
    Where(1000 < db.tbl_remuneration.money && db.tbl_remuneration.money < 4000) +
    OrderBy(Asc(db.tbl_remuneration.money), Desc(db.tbl_staff.name))
    );

これにより、より自由にSQLを組み立てることができるようになります。
例えば、Case式のWhen、Thenを条件によって追加とかね。

//checkMiddleが有効の時のみWhen、Thenの句を追加
//空のSqlは文字列に変換するときに消える
var whenThen = checkMiddle ? 
                  Db<DB>.Sql(db => When(db.tbl_remuneration.money < 3000).Then("Middle")) :
                  new Sql<string>();

var sql = Db<DB>.Sql(db =>
    Select(new SelectData
    {
        Type = Case<string>() +
                    When(db.tbl_remuneration.money < 2000).Then("Cheap") +
                    whenThen +
                    Else("High") +
                End()
    }).
    From(db.tbl_remuneration).
        Join(db.tbl_staff, db.tbl_remuneration.staff_id == db.tbl_staff.id).
    Where(1000 < db.tbl_remuneration.money && db.tbl_remuneration.money < 4000).
    OrderBy(Asc(db.tbl_remuneration.money), Desc(db.tbl_staff.name))
    );

是非お試しください!

最近のLambdicSql - PCL(Xamarin)でも使えます

github.com

この世の全てのSQLC#で表現してやる!
ってことでマルチプラットフォーム対応もしました。
.NETCoreやPCLでも使えます。

SQLiteと連携

Xamarinって言ったらSQLiteです。
LambdicSqlはSQLiteとの連携機能も入れています。
まずは、LambdicSqlとsqlite-net-pclをインストールします。
f:id:ishikawa-tatsuya:20170127094450p:plain
そして、使うところで以下をusingします。
フィーチャーしてますw

using LambdicSql.feat.SQLiteNetPcl;

これで準備完了。
以下コードです。
テーブル作って、Insertして、Selectしてます。
まあ、テーブルの生成とかInsertはSQLite自体に便利なのがあるから使うことはあんまりないと思いますが、Selectは細かくやりたいときは便利に使えると思います。サブクエリとかね。もちろん入れ子のサブクエリとかもっと複雑なのも書けますよ。

using System;
using SQLite;
using LambdicSql;
using LambdicSql.feat.SQLiteNetPcl;
using static LambdicSql.Symbol;
using System.Collections.Generic;

namespace LambdicSqlTest
{
    public class Staff
    {
        public int id { get; set; }
        public string name { get; set; }
    }

    public class Remuneration
    {
        public int id { get; set; }
        public int staff_id { get; set; }
        public DateTime payment_date { get; set; }
        public decimal money { get; set; }
    }

    public class DB
    {
        public Staff tbl_staff { get; set; }
        public Remuneration tbl_remuneration { get; set; }
    }

    public class SelectedData
    {
        public string Name { get; set; }
        public DateTime PaymentDate { get; set; }
        public decimal Money { get; set; }
        public decimal Total { get; set; }
    }

    public static class SqlSample
    {
        public static List<SelectedData> Test(SQLiteConnection con)
        {
            DeleteTablesTest(con);
            CreateTablesTest(con);
            InsertTest(con);
            return SelectTest(con);
        }

        static void DeleteTablesTest(SQLiteConnection con)
        {
            var deleteRemuneration = Db<DB>.Sql(db => DropTable(db.tbl_remuneration));
            con.Execute(deleteRemuneration);

            var deleteStaff = Db<DB>.Sql(db => DropTable(db.tbl_staff));
            con.Execute(deleteStaff);
        }

        static void CreateTablesTest(SQLiteConnection con)
        {
            var createStaff = Db<DB>.Sql(db => CreateTable(
                db.tbl_staff,
                new Column(db.tbl_staff.id, DataType.Int(), NotNull(), PrimaryKey()),
                new Column(db.tbl_staff.name, DataType.VarChar(50), NotNull())
                ));
            con.Execute(createStaff);

            var createRemuneration = Db<DB>.Sql(db => CreateTable(
                db.tbl_remuneration,
                new Column(db.tbl_remuneration.id, DataType.Int(), NotNull(), PrimaryKey()),
                new Column(db.tbl_remuneration.staff_id, DataType.Int(), NotNull()),
                new Column(db.tbl_remuneration.payment_date, DataType.VarChar(50), NotNull()),
                new Column(db.tbl_remuneration.money, DataType.Decimal(), NotNull())
                ));
            con.Execute(createRemuneration);
        }

        static void InsertTest(SQLiteConnection con)
        {
            var insertStaff = Db<DB>.Sql(db =>
                InsertInto(db.tbl_staff, db.tbl_staff.id, db.tbl_staff.name).
                Values(1, "taro-yamada"));
            con.Execute(insertStaff);

            var insertRemuneration = Db<DB>.Sql(db =>
                InsertInto(db.tbl_remuneration,
                    db.tbl_remuneration.id,
                    db.tbl_remuneration.staff_id,
                    db.tbl_remuneration.payment_date,
                    db.tbl_remuneration.money).
                Values(1, 1, DateTime.Today, 300000));
            con.Execute(insertRemuneration);
        }

        static List<SelectedData> SelectTest(SQLiteConnection con)
        {
            var min = 3000;

            var sql = Db<DB>.Sql(db =>
                Select(new SelectedData
                {
                    Name = db.tbl_staff.name,
                    PaymentDate = db.tbl_remuneration.payment_date,
                    Money = db.tbl_remuneration.money,
                    //サブクエリとかね
                    Total = Select(Sum(db.tbl_remuneration.money)).From(db.tbl_remuneration)
                }).
                From(db.tbl_remuneration).
                    Join(db.tbl_staff, db.tbl_staff.id == db.tbl_remuneration.staff_id).
                Where(min < db.tbl_remuneration.money && db.tbl_remuneration.money < 1000000)
                );

            return con.Query(sql);
        }
    }
}

呼び出し元です。

public override void ViewDidLoad()
{
    base.ViewDidLoad();

    // Perform any additional setup after loading the view, typically from a nib.
    Button.AccessibilityIdentifier = "myButton";
    Button.TouchUpInside += delegate
    {
        string dbPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.Personal), "test.db3");
        var con = new SQLiteConnection(dbPath);
        var datas = SqlSample.Test(con);
        var title = string.Format("data count = {0}", datas.Count);
        Button.SetTitle(title, UIControlState.Normal);
    };
}

しかし、VS for Mac でビルドが通らない・・・

で、動かそうと思ってMacの方に持っていくと・・・
ぐはっ、コンパイル通らんやんけ!
なんも曖昧ちゃうわ!
f:id:ishikawa-tatsuya:20170127102333p:plain
なんかわからんけど、拡張メソッドが解決できないみたいです。まあ、まだプレビューなので大目に見よう・・・。
LambdicSqlは分解して書けるので以下のように書き換えました。

static List<SelectedData> SelectTest(SQLiteConnection con)
{
    var min = 3000;

    //一つづつ作って
    var select = Db<DB>.Sql(db =>
        Select(new SelectedData
        {
            Name = db.tbl_staff.name,
            PaymentDate = db.tbl_remuneration.payment_date,
            Money = db.tbl_remuneration.money,
        }));
    var from = Db<DB>.Sql(db => From(db.tbl_remuneration));
    var join = Db<DB>.Sql(db => Join(db.tbl_staff, db.tbl_staff.id == db.tbl_remuneration.staff_id));
    var where = Db<DB>.Sql(db => Where(min < db.tbl_remuneration.money && db.tbl_remuneration.money < 1000000));

    //+で結合
    return con.Query(select + from + join + where);
}

でもこれは、メソッドチェーンでなくて、+演算に変えろっていうお告げなのか?

で実行結果です。
f:id:ishikawa-tatsuya:20170127104401p:plain:w250

最近のLambdicSql - この世の全てのSQLをC#で表現する

github.com
まだβ版です。とはいえ、今度こそ着実にリリースに近づいています。
この辺で最近入れた機能をご紹介させていただきます。
それは句や関数を簡単に追加できる機能です。

この世の全てのSQLC#で表現するポテンシャルを持たせました。

若干言い過ぎ感はありますがw
LambdicSqlは多くの句や関数がデフォルトで組み込まれています。今のところの判断基準は私が読んだSQLの入門書に書かれていたものです。(えっ?)でも、もちろんこれでは足りず、かといって全網羅するのは大変だしなーってことで、ユーザー側で簡単に追加できるようにしました。
LambdicSql自体も、ここで解説している仕組みを使って関数や句を定義しているので、それがサンプルになると思います。よろしければ参照してください。

一般的な関数の追加

FuncStyleConverterAttributeをつけるだけで使えるようになります。
以下のルールで変換できます。

  • 関数名はC#のものが大文字にって使われる(Nameプロパティで別途指定も可能)
  • 引数に括弧がつく
  • 間がカンマで区切られる
//使いたい関数を定義
static class MyFuncs
{
    [FuncStyleConverter]
    internal static Cos(double angle) { throw new NotSupportedException(); }
}

それで定義の中身なのですが、実行されることはないので空っぽでOKです。(Exceptionの解析に使われるだけです)
using static MyFuncs;
を書いておくとよりSQLっぽさがでます。

//使える!
void Test()
{
    var sql = Db<DB>.Sql(db =>
        Select(new SelectedData
        {
            Val = Cos(db.tbl1.angle),
        }).
        From(db.tbl1)                
    );

    Console.WriteLine(sql.Build(_connection.GetType()).Text);
}

こんな感じで変換されます。

SELECT
        COS(tbl1.angle) AS Val
FROM tbl1

一般的な句の追加

ClauseStyleConverterAttributeを使います

  • 句名はC#のものが大文字にって使われる(Nameプロパティで別途指定も可能)
  • 句と第一引数の間はスペースで区切られる
  • 間がカンマで区切られる

句は結構実装したので良いのが思いつきませんでした。
それでLambdicSqlで定義してますがサンプルはLIMIT句を使います。

//使いたい句を定義 
static class MyFuncs
{
    [ClauseStyleConverter]
    public static ClauseChain<Non> Limit(object offset, object count) { throw new InvalitContextException(nameof(Limit)); }

    [ClauseStyleConverter]
    public static ClauseChain<TSelected> Limit<TSelected>(this ClauseChain<TSelected> before, object offset, object count) { throw new InvalitContextException(nameof(Limit)); }
}

句はどうしてもメソッドチェーンでつなげたいですよね。なのでClauseChainというクラスの拡張メソッドとして定義してもらうとOKです。それでバラバラに書いて後でくっつけたい場合もあるので拡張ではないバージョンも定義しておくと便利です。

void Test()
{
    var sql = Db<DB>.Sql(db =>
            Select(Asterisk(db.tbl_remuneration)).
            From(db.tbl_remuneration).
            OrderBy(Asc(db.tbl_remuneration.id)).
            Limit(1, 3)
            );

    Console.WriteLine(sql.Build(_connection.GetType()).Text);
}
SELECT *
FROM tbl_remuneration
ORDER BY
	tbl_remuneration.id ASC
LIMIT @p_0, @p_1

フォーマットを自分で指定するもの

とは言え、別のフォーマットのものもありますよ。ということでフォーマットを指定したい場合はMethodFormatConverterAttributeを使います。ついでにenumを使いたい場合の説明も。
TABLESAMPLEでやってみます。

static class MyFuncs
{
    [MethodFormatConverter(Format = "TABLESAMPLE [0](|[1])")]
    public static ClauseChain<Non> TableSample(SamplingMethod method, double percentage) { throw new InvalitContextException(nameof(Limit)); }

    [MethodFormatConverter(Format = "TABLESAMPLE [1](|[2])")]
    public static ClauseChain<TSelected> TableSample<TSelected>(this ClauseChain<TSelected> before, SamplingMethod method, double percentage) { throw new InvalitContextException(nameof(Limit)); }
}

[EnumToStringConverter]
public enum SamplingMethod
{
    //大文字になる
    System,

    //別途文字列指定もできる
    [FieldSqlName("BERNOULLI")]
    Bernoulli
}
void Test()
{
    var sql = Db<DB>.Sql(db =>
            Select(Asterisk(db.tbl_remuneration)).
            From(db.tbl_remuneration).
            OrderBy(Asc(db.tbl_remuneration.id)).
            Limit(1, 3)
            );

    Console.WriteLine(sql.Build(_connection.GetType()).Text);
}
SELECT *
FROM tbl_remuneration
TABLESAMPLE SYSTEM(@p_0)

Formatで指定した感じに文字列化されます。登場する記号類です。

記号 内容
| 改行が入る場合でも、その位置までは一行目に残す
[i] i番目の引数を入れる
[<, >i] i番目の引数を展開する。その引数は配列である必要がある。<>の中はセパレータを指定する。
[$i] パラメータを使わず直値でSQLに文字列として入れる
[#i] カラムが入った場合テーブル名なしでカラム名のみにする
[!i] 特殊文字列。指定された文字列を直接SQLに入れる。db名や制約名称に利用。

さらに特殊な場合

MethodConverterAttributeを継承します。実は他にもnew、フィールド、プロパティ、オブジェクトを変換することもできます。

MethodConverterAttribute メソッド
NewConverterAttribute コンストラクタ
ObjectConverterAttribute オブジェクトの変換。型に使う
MemberConverterAttribute フィールド、プロパティー

Expressionがわたってくるのでそれを解析して、コードにして返します。
LambdicSqlでもいくつかはこれを使っているのでサンプルとしてはこちらを参照お願いします。

public abstract ICode Convert(MethodCallExpression expression, ExpressionConverter converter);

仲間を募集中

ユーザー定義で増やせるとは言え、デフォルトで入ってた方が良いですよねー。なのでもっとLambdicSqlで定義されている分を増やしたい。今は一つのクラスに定義してるけど、DB別とかで定義したら、そのDBで使えるものだけインテリセンスにでて便利度UPですよね。でも一人では工数が足りない・・・。だれか一緒に、すべてのSQLをC#で表現しませんか?仲間募集中です!

Expression中の値を取り込む

C# Advent Calendar 2016の記事になります。26日ですが、今朝見たら空きがあったので書かせてもらうことにしました。
私は趣味でOSSのライブラリを作ってます。テスト自動化用のライブラリのFriendlyとか、最近はLambdicSqlというC#のラムダでSQLを作成するライブラリを作っています。
こんな感じでC#ラムダ式を書くと、そのまま文字列とパラメータになります。
Dapperと組み合わせるとそのまま実行可能です。
それからEntityFrameworkと組み合わせて使うこともできるようにしています。(β版リリース時の記事もご紹介。)

var min = 3000;

//C#からSQL作成
var query = Db<DB>.Sql(db =>

    //ここに書いたラムダが(割と)そのままSQLになる!
    Select(new SelectData()
    {
        Name = db.tbl_staff.name,
        PaymentDate = db.tbl_remuneration.payment_date,
        Money = db.tbl_remuneration.money,
    }).
    From(db.tbl_remuneration).
        Join(db.tbl_staff, db.tbl_staff.id == db.tbl_remuneration.staff_id).
    Where(min < db.tbl_remuneration.money && db.tbl_remuneration.money < 4000)
    
);

//文字列とパラメータ作成
var info = query.Build(_connection.GetType());
Debug.Print(info.Text);

//Dapperと連携可能。Select句の型情報を持っているので、そのまま実行できるよ。
var datas = _connection.Query(query).ToList();

こんなSQLになります。

SELECT
    tbl_staff.name AS Name,
    tbl_remuneration.payment_date AS PaymentDate,
    tbl_remuneration.money AS Money
FROM tbl_remuneration
    JOIN tbl_staff ON (tbl_staff.id) = (tbl_remuneration.staff_id)
WHERE ((@min) < (tbl_remuneration.money)) AND ((tbl_remuneration.money) < (@p_1))

例のようなシンプルなSQLだけではなくサブクエリとか内部結合とか、かなり複雑なSQLも記述可能です。
絶賛実装中なのです。当初の予定より遅れてますが、年明けくらいには1.0にする予定です。βにしたもののやってたら、やりたいこと増えていくんですよね・・・。

Expression中の値を取り込む

で、今回の本題です。Expression中の変数の取り込みに関してです。最小な感じにして以下で考えます。

var min = 100;
var query = Sql<DB>.Create(db => min < 4000);

端折りますが受けているところはこんな感じでexpression.Bodyから解析を開始します。

public static SqlExpression<TResult> Sql<TResult>(Expression<Func<TDB, TResult>> expression)
{
    //解析スタート
    expression.Body;
}

これを解析していくとこんな感じになっています。
BinaryExpression
  Left
    FieldExpression
      (min)
  Right
    ConstExpression
      Value (4000)

定数の取り込み

上の例で4000は定数です。これはコンパイル時に決まります。こういうのは解析していくとConstantExpressionという式で表されます。これは簡単でValueに値が入っているのでそれを取得できます。

object Convert(ConstantExpression constant)
	=>constant.Value;

変数の取り込み

これがポイントです。リフレクションを使うか式木をコンパイルしないと値が取れないんですよね。値が取れるとこまでExpressionを解析します。今回の場合だとすぐにConstExpressionになってValueにはminを保持しているobjectが取得できます。(本来は色々場合分けがありますが今回は端折ります)

object GetMemberObject(MemberExpression exp)
{
    var constant = member.Expression as ConstantExpression;
    var obj = constant.Value;
}

objの型は以下のものになっています。
{Test.Samples.<>c__DisplayClass73_0}
そんな型作った覚えないよって感じなのですが、コンパイル時に作られる型です。変数引き渡し用ですね。

で、objが取れるので
引数を一つとって、そのオブジェクトのメンバのminを返す式木を作ります。

var param = Expression.Parameter(obj.GetType(), "param");
var exp = Expression.PropertyOrField(param, member.Member.Name);

ここで問題なのは、objがobject型なので誰かがそれに静的な型を付与してやらないと、上手く呼び出せないことですね。キャストの式を入れても良いのですが、今回は Type Erasure というパターンを使うことにします。
静的な型が必要ないインターフェイスを用意し、それを実装するクラスが静的な型を持っているというものですね。それによって使う側は静的な型が必要なく使えます。

interface IGetter
{
    void Init(Expression exp, ParameterExpression[] param);
    object GetMemberObject(object[] arguments);
}
class GetterCore<T0> : IGetter
{
    public delegate object Func(T0 t0);
    Func _func;
    public void Init(Expression exp, ParameterExpression[] param) => _func = Expression.Lambda<Func>(exp, param).Compile();
    public object GetMemberObject(object[] arguments) => _func((T0)arguments[0]);
}
var getter = Activator.CreateInstance(typeof(GetterCore<>).MakeGenericType(type), true) as IGetter;
getter.Init(Expression.Convert(param, typeof(object)), new[] { param });
var value =  getter.GetMemberObject(new object[] { obj });

コンパイルすると遅い

このコンパイルはハイコストです。毎回やったら遅いですね。(最初は毎回やってたんですけどね・・・)なんでキャッシュします。上のではIGetterをキャッシュしておけばよいです。LambdicSqlではこの他にメソッド呼び出しとかオブジェクトの生成とかコンパイルが必要になるケースはすべてキャッシュするようにしました。それによってかなり高速にLambda→SQL変換ができるようになりました。(アドバイスをくれた皆様ありがとうございました!)

実はExpression化するだけでもコストがかかる

例えば、こんなコードでもタダではありません。私もやるまで「これはコンパイル時に決定されるよねー」とか勘違いしていたのですが、当然そんなことはなくExpressionの中に変数取り込んだりでコストは発生しているのです。しかも中の式が複雑になればなるほど、その時間は長くなるのです。

void Test()
{
    var min = 100;
    Empty(() => min < 4000);
}
static void Empty<T>(Expression<Func<T>> expression){}

つまり、がんばってパフォーマンスチューニングはしたものの限界はあります。多くのケースでは無視しても良いくらいなのですが、シビアなケースも考えLambadicSqlではユーザー側でキャッシュしやすい設計にしています。

Expression解析に興味があれば

github.com
結構Expression解析実装したのでサンプルになる部分もあるかも。興味があれば、見てみてください。
そんで、もうすぐ1.0リリースします。今もベータですが公開しているので興味があればNugetからご利用お願いします!
www.nuget.org

一日おくれですが、メリークリスマス!