Incremental view maintenance is a difficult problem in SQL implementations. The idea behind view materialization and incremental maintenance is that some scenarios provide that it is optimal to pay the maintenance cost up front as opposed to constructing the view each and every time it is read.

This concept can also be related to objects within an application. There may be data repositories within memory that are constantly being updated. As a client of those repositories, it may be necessary to create, maintain and display some view of that data to the user. I believe we can apply classic solutions to view materialization and incremental view maintenance by using linq production rules to make that job much more declarative, functional, and maintainable.


Imagine two weakly related collections of dynamically maintained lists of data:

	var shoeData = DataSource.ShoeView;
	var familyData = DataSource.FamilyView;

What I'd like to do is be able to define a query like so:

	var query =  from s in new ViewQuery<Shoe>(shoeData)
        	     join p in new ViewQuery<Person>(familyData) on s.Name equals p.Name
                    where p.Name == "Dana" && s.Brand == "Puma" || s.Brand == "Ugz"
                    select new{ p.Name, s.Brand, s.ShoeSize };
	var view = query.CreateView();

This will create a new view to be maintained within the application. For every change that happens in the ShoeView or the FamilyView, the new view will reflect those changes dynamically and in a thread safe way. It should be robust enough to handle those data sources being updated on independent background

The view will have access methods to retrieve data either in a streaming fashion, or a
snapshot fashion.

	var data = view.GetData();

Alternatively, the client should be able to handle the incremental updates of the view.

	view.StreamData(burst => {
                foreach (var msg in burst)
                    // handle each updata/add/remove of data individually

Last edited Jun 30, 2009 at 11:42 PM by SayreBlades, version 13