@jsakamoto

ASP.NET Dynamic Data + ADO.NET Entity Framework で SQLite - オートナンバーで問題発生

先日、ASP.NET Dynamic Data + ADO.NET Entity Framework で SQLite を扱うエントリを投稿したが、一点、不具合があった。

主キーとして auto-increment な列、いわゆる "オートナンバー" 列として作成してあるテーブルについて、ASP.NET Dynamic Data の [新しい項目の追加] ページにてレコード追加すると例外が発生してしまうのだ。

例外の詳細はこんな感じ。

System.Data.SQLite.SQLiteException: Abort due to constraint violation
PRIMARY KEY must be unique

"主キーがユニークじゃないです" とのこと。

前提としては、この主キー列についてのエンティティクラスに対しては、"オートナンバー" であるわけなので、ASP.NET Dynamic Data のページに露出しないよう、メタデータクラスにてスキャフォールディングを無効にしておいた場合である。

例)
[MetadataType(typeof(MyTableMetaData))]
public partial class MyTable { }
public class MyTableMetaData
{
　[ScaffoldColumn(false)]
　public object ID { get; set; }
　...

さて、SQLite では、とりたてて "オートナンバー" 列にしてね、という明確な指定があるわけではないようで、integer で、かつnull不許可で、かつ主キーである列が、オートナンバー的に振る舞うそうである。
Google で "SQLite オートナンバー" を検索し、見つかった Yahoo! 知恵袋のページからたどり着いたのが下記のサイト。

「SQLite で auto-increment なフィールドを作成する方法」
http://cl.pocari.org/2006-02-12-1.html

たぶん、このような背景に起因して、ASP.NET Dynamic Data 側で、SQLite の "オートナンバー" (のつもり) 列を、”オートナンバー" 列であると知ることができず、常に既定値の 0 に初期設定されたまま INSERT 文を実行して、結果、主キー重複の例外と相成るのであろう。

ASP.NET Dynamic Data 側で "オートナンバー" 列に対してどのような挙動が仕組まれているのか知識もなかったので、少々力業であるが、自前のコードで事前に "次の番号" をクエリするようにした。

まずは /DynamicData/PageTemplate/Insert.aspx をいじる。

DetailsView コントロールがひとつ貼り付けられているので、この DetailsView コントロールの ItemInserting イベントをハンドル。
このイベントのタイミングで次のID値を求めるのだ。

このイベントハンドラの内容は次のとおり。
if (table.HasPrimaryKey
&& table.PrimaryKeyColumns.Count == 1
&& table.PrimaryKeyColumns[0].ColumnType == typeof(Int64))
{
　var context = table.CreateContext() as ObjectContext;
　var query = string.Format("SELECT VALUE MAX(it.{0}) FROM {1} AS it",
　　table.PrimaryKeyColumns[0].Name,
　　table.DataContextPropertyName);
　var result = context.CreateQuery(query).First() ?? (Int64)(-1);
　e.Values.Add(table.PrimaryKeyColumns[0].Name, result + 1);
}

Insert ページクラスには MetaTable 型の table インスタンス変数が備わっており、この table 変数から必要な情報は概ね手に入る。

まず、対象テーブルが主キー列を1つだけ持ち、かつその主キー列の型が Int64 ( SQLite における integer )である場合にのみ、動作するようにする。

その上で table インスタンス変数を頼りにアドホックな Entity SQL 文を構築し、同じく table インスタンス変数からコンテキスト入手のしてクエリを発行、現在のID値の最大値を手に入れる。

あとは、ItemInserting イベントの引数に対して、この主キーに設定するパラメータを追加して終わりである。
( そうそう、SQLite の "オートナンバー" のつもりの列は、値を明示的に指定して INSERT しても OK なのだ )

というわわけで、いちおうの実装は終えた。

しかし、このコードは同時実行については弱い（全体をトランザクションで保護できていない）。
また、せっかくの SQLite の "オートナンバー" っぽい機能をまったく利用していない。
とりあえず今回の要件では、これらの課題は問題にはならないため、このままで済ませたが、本来ならば、もっと踏み込んで解決すべきとは思う。

ASP.NET MVC と ASP.NET Dynamic Data の同居 - 実例

前回の投稿で言及したASP.NET MVC と ASP.NET Dynamic Data の同一Webアプリ内での同居について、その実践・実例。

自分の場合は次のように進めた。
内容的には下記と同じ。
どっとねっとふぁんBlog「通常のASP.NETとASP.NET Dynamic DataとASP.NET MVCを組み合わせる」
http://dotnetfan.org/blogs/dotnetfanblog/archive/2008/10/02/2823.aspx


まずは、新規に、ASP.NET MVC と ASP.NET Dynamic Data の Webアプリプロジェクトを、それぞれ別々に作成。

次に、ASP.NET MVC プロジェクトへ、ASP.NET Dynamic Data プロジェクトのファイルを追加していった。

もう少し具体的に書くと、ASP.NET Dynamic Data プロジェクトの ~/DynamicData フォルダを、ASP.NET MVC プロジェクトを開いている Visual Studio のソリューションエクスプローラ上へ、エクスプローラを使ってドラッグ & ドロップすることでまるごと追加。

あと、ASP.NET Dynamic Data プロジェクトの ~/Default.aspx は MVC プロジェクトのそれと名前がかぶるので Tables.aspx に変更の上(※もちろん、クラス名も適宜手作業で変更)、~/Site.master、~/Site.css と一緒にエクスプローラを使って MVC プロジェクトへドラッグ & ドロップで追加。

続けて、MVC プロジェクトの参照設定に、Dynamic Data の動作に必要なアセンブリへの参照を、Dynamic Data プロジェクトの構成を横目で見ながら追加。

web.config には、同じく Dynamic Data プロジェクトの web.config を参考にしつつ、configuration/system.web/pages/controls に <add ragPrefix="asp" namespace="System.Web.DynamicData" .../> の行を追加。

最後に、MVC プロジェクトの Global.asax.cs に、Dynamic Data のためのルート設定を追加。
すなわち、MVC プロジェクトの Global.asax.cs 中、RegisterRoutes static メソッド内の先頭に、Dynamic Data プロジェクトの Global.asax.cs 中の RegisterRoutes static メソッドの内容をまるごとコピーして挿入した。

以上でとりあえず完成。

別途エンティティ用意して Global.asax.cs 中でデータモデル登録したりスキャフォールディング有効にしたりすれば、~/Tables.aspx を開くことで Dynamic Data サイトとして動作していることが確認できる。

なお、外部CSSファイルが MVC と Dynamic Data とで別々だったりするので、これを統一化したり、いろいろとまだまだ外見の微調整が必要である。

ちょっとしんどいのは、マスターページが MVC と Dynamic Data とで別々であること。
MVC のマスターページは、System.Web.Mvc.ViewMasterPage クラスなので、Dynamic Data と共用するのは無理っぽい。
求む良いアイディア、といったところ。

むしろ、Dynamic Data for MVC のリリースを待つべきなのか。

あるいは、ASP.NET MVC でもRCないしはRTMでは Dynamic Data とは方向性がちょっと違うものの、ビューのスキャフォールディングサポートがあるので、Dynamic Data はあきらめて、MVC のスキャフォールディングサポートだけでこなしても、そんなに生産性が落ちることもないかもしれない（本エントリのようにごちゃごちゃやるくらいなら）。

ADO.NET Entity Framework で SQLite を扱う - ASP.NET Dynamic Data も OK!

先日のエントリで、ADO.NET Entity Framework で SQLite データベースファイルを取り扱う需要について投稿した。

で、今回は実践。
結論としては、ADO.NET Entity Framework による SQLite データベースアクセスはバッチリ動作する。

以下、証拠写真集。
なお、ADO.NET Provider for the SQLite（System.Data.SQLite）および Visual Studio IDE 統合機能がすでにインストールしてあることが前提。

まずは Visual Studio 2008 Pro SP1 を起動し、プロジェクトを作成（または既存プロジェクトを開く）。

次に、SQLite のデータベースファイルを生成しつつ、Visual Studio IDE にデータベース接続を作成する。
Visual Studio のサーバーエクスプローラから、データベース接続の追加を開始。
既定のプロバイダによる「接続の追加」ダイアログが現れるので、データソースの [変更(C)...] をクリック。
データソースから SQLite のデータベースファイルを選択する。
改めて、SQLite のプロバイダで「接続の追加」ダイアログが現れる。
[New...]をクリックして新規に SQLite データベースファイルを作成してもよし、既存の SQLite データベースファイルを [Browse...] から選択してもよし。いずれの場合でも、直接フルパスを直入力してもかまわない。

以上でデータベース接続ができあがり。
続けてここからテーブル定義の作成や変更、「データの取得」メニューからの表形式 GUI でのレコードの参照/追加/変更/削除ができる。

詳しくは下記が大変参考になる。
「Visual Studio 2005 / Visual Studio 2008からSQLite3をつかう」
http://blogs.wankuma.com/hatsune/archive/2008/10/15/158833.aspx
(* 上記ブログエントリでは、「データの取得」では、参照しかできないとのことであったが、本稿投稿時点ではレコード追加/編集/削除も可能であった)
さてここからが実は本題、次は Entity Framework である。
プロジェクトに新規 ADO.NET Entity Data Model(.edmx) を追加し、モデルコンテンツの選択にて、[データベースから生成] を選んで次へと進むと、先ほどサーバーエクスプローラに追加した SQLite データベースファイルへの接続を選ぶことができる。
すると、ちゃんと SQLite データベースファイルを読み取って、モデルに含めるデータベースオブジェクトを選択できる。
最終的にはご覧のとおり、デザイナ画面にて表示される。

あとは LINQ to Entity などのデータアクセステクノロジを使って、自由に参照/追加/変更/削除が可能である。

もちろん、ASP.NET Dynamic Data でも問題なし。

また、ASP.NET Web アプリケーションの場合は、web.config ファイルに記述する接続文字列中、SQLite データベースファイルへのパスを、"|DataDirectory|" 置換文字列を含めて指定することもできた（つまりこの場合、SQLite データベースファイルは、App_Data フォルダ以下に配置する。なお、web.config の記述を直接テキストエディタで変更すること。.edmxのデザイナ画面からは変更できない。）。

なお、残念ながら Visual Web Developer Express 2008 SP1 では、サーバーエクスプローラやデータベースデザイナの機能制限から、上記の説明のとおりにはできないことがわかっている。
ほかの Express Edition もおそらく同様であろう。

2009/10/27 追記
Visual Web Developer 2008 Express でも、ADO.NET Provider for SQLite のデータベースデザイナ支援を機能させることに成功。

動作確認できたのは Pro Edition。Standard Edition は持ち合わせがないため、本エントリで示したような操作が可能かどうか不明である。

ASP.NET MVC と ASP.NET Dynamic Data の同居

先日のエントリで ASP.NET Dynamic Data サイトでファイルベースのデータベースを取り扱うことに言及したが、実はこのサイト、ASP.NET MVC で構築した。

つまりは、ASP.NET MVC と ASP.NET Dynamic Data の同居である。

この同居、試行錯誤しつつ、あんまりスマートとはいえないものの、とりあえず構築はできたのだが（詳しい顛末は機会があれば後日）、ふと CodePlex の ASP.NET プロジェクトを開いてみると...

Dynamic Data for MVC Preview
http://www.codeplex.com/aspnet/Release/ProjectReleases.aspx?ReleaseId=15459

"for MVC" !?
まぁ、まだプレビューということらしいし（それをいうとASP.NET MVC もまだベータだが）、LINQ to SQL でしかまだ使えないそうだが、これを待てば MVC と Dynamic Data の同居は当たり前にできる状況になるということだろうか?

機会があれば、早期評価してみたいところ。
ただし、LINQ to SQL ではなく、ADO.NET Entity Framework をサポートしてくれてからの話になりそうだが。

ASP.NET DynamicData で、ちょっとこれはどうかな、と感じたところ

ASP.NET Dynamic Data を是非活用しようといろいろ試行中。

なにはともあれ Dynamic Data を使って、顧客名のマスタメンテナンスプログラムを模擬して試験プログラムを作成してみた。

...ちょっとフォントが汚い感じがする。

Site.css の末尾に「* { font-family:Verdana; }」を追加して回避。

次に、顧客一覧のページに進んでみた。

...ちょっと間延びしすぎな感じがする。

Site.css の末尾に「table.gridview { width: auto; }」を追加して回避。

ただし、これだとテーブル一覧のページがこんどは逆にカッコ悪くなってしまうが、後日対策を検討することとしよう。

削除ボタンを押してみた。

...メッセージが英語。

/DynamicData/PageTemplate/List.aspx 内に、「削除」リンクボタンの OnClientClick プロパティに confirm 関数呼び出しがハードコードされているので、これを日本語の文面に変更して回避。

ところで、この一覧ページ、コマンド系のリンクボタンが左端にあるのが、少々気持ち悪い。
これは慣れとか文化の問題だったりするので、これでもいいのだとは思うが、ASP.NET の GridView のカラム自動生成の場合だとコマンド系のリンクボタン類は右端に配置されたりすることもあって、右端にコマンドを配置するのに慣れている。
Dynamic Data でも、右端に配置することができるんじゃないだろうか?

ということで、/DynamicData/PageTemplate/List.aspx をいじり、まずは GridView の RowDataBound イベントをハンドル。

<asp:GridView ID="GridView1" runat="server" DataSourceID="GridDataSource"
...OnRowDataBound="GridView1_RowDataBound">

/DynamicData/PageTemplate/List.aspx.cs にイベントハンドラを記述し、ここで列の差し替えを実装。

protected void GridView1_RowDataBound(object sender, GridViewRowEventArgs e)
{
// 編集コマンド列を右端に差し替え
var _1stcell = e.Row.Cells[0];
e.Row.Cells.RemoveAt(0);
e.Row.Cells.Add(_1stcell);
}



これにて右端にコマンド系リンクボタンを配置することに成功。

Dynamic Data はあくまでひな形、スタートラインだと考えれば、これくらいいじるのはどうということはないのだが、しかし、フォントと削除時の英語メッセージくらいはもう少し気遣って頂ければうれしかったところ。

βかCTPかRCかのときに、コメントできていればよかったのだろうが、まぁ、こちらにも仕事の都合があるので、そこはやむを得ない。

遅まきながら、フィードバックセンターにでも投稿してみようかと思案中。