This post is a couple days over due.
When last we left NOODB, I was carving out the custom xml serializer which ended up not being necessary. Whoops. Instead, it “serializes” into an object graph that is, essentially, nested name value pairs. When the server is local, it can pass a reference. When the server is remote, the object can be passed via WCF. There won’t be any known type issues.
I’ve been saying that needs to be done for a while. It became necessary when I started working on projections. (In particular, I need to be able to do “from r in MovieReview select r.*, –r.ReviewText”, or something like that.) That involves analysis of the final set of selected properties and passing it to the data context. It’s the last part that prompted the gutting; I would’ve had to put it in a lot of places that I knew was going to be cut out, so didn’t want to do it twice.
That’s all done. NOODB is back to 100% functionality without the custom serializer. Additionally, it passes the property ids to the data context.
The next big thing, which I’ve been stalling on for the last couple days, is the property resolution part. Based on the fields and patterns you select, it has to figure out all of the property ids. It’s a daunting task that’s hard to commit to while coding and watching tv at the same time. This is one of those things where I should go up to the office and focus on it, but we just had a baby. I don’t drag my butt upstairs any more than I need to. Besides, I need my TV.
All of the meta data for the analysis is collected and ready to go. The big piece is resolving it. It’s complicated. Consider, for example that you have an object A with a property B, and B has a property C. The select may say “a.Property1, c.Property3.”
There are 3 objects and we’re not selecting anything from the one in the middle. As it figures out the properties to get, it has to know that “hey, even though they didn’t request anything from b, I have to get b anyway in order to get to c.”
Logically, does this make sense? B will come back empty except for the one property that is C. No, it probably won’t make sense, but that’s not my decision, it’s yours. The syntax of the query allows you to specify stuff like that, so the query engine will do stuff like that. Whether or not it’s a good idea is up to you. If your just dumping a bunch of stuff to a grid or some other read-only presentation, then it may be just fine.
In a related story, I’ve put a lot of thought into the syntax of the selects, and here’s what I’m going with, at least for now.
It’s going to start with the first projection, then just keep applying the other projections on top of it. The last ones win.
Get all everything in R except for the review text. r.* is shallow; it won’t get child objects, just the properties of R.
r.**, –r.Movie.Director, –r.Author, r.Author.Name
Get everything in R, including the child objects. Then remove the movie’s director, and the review’s author, then put back the author’s name.
Once this is all working, the next step will be to return the values in a flat format rather than a graph. If you just want to dump the results onto a grid or something, then you don’t need the graph, you just want some values.
Tonight, I begin work on the property resolver. Tomorrow, I rest.