認知的プログラミング - LINQ to SQL on SQLCLR

SQL Server 2008 から SQLCLR で LINQ を使うことはできるようになりましたが、LINQ to SQL は使えません。

static メンバの罠

VisualStudio 2008 の O/R デザイナで、テーブルを取り込むと VS2008 が、DataContext の派生クラスを自動生成しますが、この先頭に static メンバが定義されてます。

	public partial class DataClasses1DataContext : System.Data.Linq.DataContext
	{
		
		private static System.Data.Linq.Mapping.MappingSource mappingSource = new AttributeMappingSource();

	}

SQLCLR では、動的 static プロパティが使えないので、無理矢理 SQLCLR に LINQ to SQL クラスを取り込んでも、配置できないという目に遭います。せっかく System.Data.Linq が使えるようになったのに、LINQ to SQL が使えないのでは、非常にもったいない気がします。

何か良い方法は無いもんでしょうか？

アセンブリをアンセーフにすればいいんじゃね？という話もなくはないですが…まぁ避けた方が賢明でしょうね。

#追記

中の人が "not aware of plans" と言っているので、実装されないかもしれませんね。
http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2007/11/13/9930.aspx

自分で LINQ 対応の O/R マッピングクラスを作って、LINQ to Objects で使う方が現実的かもしれませんね。

オンメモリキャッシュ

SQLCLR 上で、テーブルを読み込んでオブジェクト化し、そのオブジェクト内部で様々な処理を行った場合、そのオブジェクトをキャッシュして、複数の Sql Function や ストアドプロシージャで共有したいなぁと思うことがあるのですが、前述の static メンバが使えないおかげで、実現できません。

テーブル上にオブジェクトをシリアライズして保存して、使うときにデシリアライズするという方法も考えられますが、速度的に疑問がわきます。

共有メモリを使うにしても、C++ の Placement New みたいな事ができるわけでもないので、結局シリアライズすることになりますし、なにより Unsafe アセンブリになってしまうので、そもそも意味が無い。

さてどうしたものでしょう。