[Mono-dev] DataContext Implementation Advice

[Paul Stovell]

Hi Kevin,

I'm enjoying reading these posts of yours - very fascinating.

With regards to change tracking, the last time I looked, DLINQ objects raise
a PropertyChanging (INotifyPropertyChanging, part of System.ComponentModel )
event when properties are changed. Since it is your QueryProvider (the
DataContext) which is returning the objects, it can subscribe to these
events and use them to builds its hashtable when updateable items are
modified.

So a Dictionary<Row, Change> (where a "Change" represents the original and
new value), as you suggested, would seem like the way to go to me.

Cheers,

Paul
www.paulstovell.net


On 9/21/07, Kevin Kubasik <kevin at kubasik.net> wrote:
>
> Ok, so I've been able to create a pretty generic (if highly adaptable)
> IQueryProvider which implements very basic Linq -> Sql support(More on
> that later). This project was to better understand the roll played by
> different components in the linq->sql pipeline. While the more
> complicated and optimized we try to make the Linq-SQL conversion, the
> harder it becomes, the core of implementing a Provider is pretty easy.
> We could write custom _query_ providers all day long and have linq to
> the world. The problem is that we want updates, deletes, sprocs etc.
> That is where the DataContext comes in, and my headaches start.
>
> The principal of the DataContext is easy enough, its like the ADO.NET
> 2.0 DataSets in that it can be generated as a strongly-typed extension
> of the core DataContex, or as a generic and adaptable class. The
> DataContext sits in System.Data.Linq, and is the gatekeeper between
> the query language and a provider. In addition to just being in the
> way, the DataContext provides metadata about a database, has an
> understanding of tables and relationships, as well as stored
> procedures. It is also responsible for object caches.
>
> This is all fun and good, with some decent mapping code we can do all
> that without breaking a sweat. The problem is
> DataContext.SubmitChanges(). As tables are manipulated etc. these
> changes are tracked in-memory (or some other awesometastic way) and
> eventually either reverted or submitted. More importantly, to anyone
> using the DataContext's tables gets the modified information. Again,
> things don't sound too bad, and there are already implementations
> (DataTable, DataSet etc.). The difference is they have all the data,
> and execute a modification upon call, then store the old value and the
> current state of the data. Linq is all deferred execution, we don't
> have an in memory representation of the data on the database, we just
> have a list of instructions, each of which will return a result.
>
> So, basically I've determined that out DataContext will have to track
> everything happening in each of its tables. This got me thinking, an
> event driven model would be perfect, we would only act when actual
> action was being taken.  Now, I basically have both ends of the
> spectrum, we get every object associated with an expression utilizing
> a DataContext, and flag it in our cool DiffTracker, using a Dictionary
> or Hashtable for fast lookups based upon the entity itself, then we
> process each event as it happens (which is pretty much the last thing
> an expression will do). I think we can get away with only the current
> state of each noteworthy object and the most recent past.I figure if
> the state is Insert, who cares what the object was before, if the
> state is Update, we just update all values to their current value,
> selecting on the old object, and if its delete.... yeah. There is a
> States.cs Enum in the System.Data.Linq directory with all the states a
> DataContext  is aware of.
>
> The problem is the massive middleman, I've gotten absolutely worlds
> better with some of C#'s more advanced language structures in the few
> days I've been working on this, but I am not 100% sure of hows the
> best way to go about this. As a result, I would really love some help.
> I can get the DataContext to respond intelligently to Linq queries,
> and continue to process the subtree into a table. Once we are at that
> point, its all on the individual Sql implementation (which isn't
> important yet, and isn't really on the immeidate radar.).
>
> If someone could help me out a bit with the actual construction of the
> DiffTracker and DiffWrapper classes, it would be greatly appreciated.
> You aren't obligated to use my design, or even help at all. But I
> would _greatly_ appreciate some feedback or any ideas anyone has about
> this. Specifically with regard too keeping this light and simple, as I
> feel like it could quickly become a massive buggy mess.
>
> --
> Cheers,
> Kevin Kubasik
> http://kubasik.net/blog
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070921/d3034ae7/attachment.html