[Mono-dev] DataContext Implementation Advice

[Kevin Kubasik]

Yeah, thats right along the line I was hoping to go before, my only
concern really stems from my lack of experience with the whole
"functional programming" workflow. I would think that adding a
listener to every entity in a DataContex's Tables. But my concern was
more over managing state accurately, and are the 'same' entities
always going to appear that way to a hash, or would it need to be a
searched list?

Just because of the mammoth amount of work that has to go into getting
the very start of a system like that working, I want to be somewhat
confident. Anyways, the upside is that I can probably use linq over
the object store ;)

On 9/21/07, Paul Stovell <lists at paulstovell.com> wrote:
> 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
> >
>
>


-- 
Cheers,
Kevin Kubasik
http://kubasik.net/blog