Getting a chance to catch up on Mike Deem’s excellent WinFS blog. I’m learning quite a bit.
It’s good to see that WinFS will share the same query language as ObjectSpaces – namely, OPath. OPath is a SQL-like query language for executing queries against object trees that that represent SQL-backed data. Under the hood, I think OPath gets converted into an equivalent SQL query which is executed against the data store, with the results being stuffed back into a nice strongly-typed object tree. This seems to be how ObjectSpaces work, and I’m guessing that WinFS works in much the same way.
Anyway, it’s interesting to see that OPath queries are nothing more than strings. From the looks of examples like this, these strings can get rather complex (code borrowed from Mike Deem’s blog):
Person.FindAll(“IncomingRelationships.Cast(System.Storage.Contacts.HouseholdMember).Household.OutgoingRelationships.Cast(System.Storage.Core.ContactLocations).Location.MetropolitanRegion = ‘New York’“ );
Having a string-based query language is fine for deterministic queries that are well-known at compile time, but generating them programmatically is a pain. Anyone who’s done non-trivial dynamic SQL knows this. You end up writing these classes that do code generation by assembling bits and pieces of many different strings, and until you’re very familiar with the target language it can be difficult to make sure your code generator always build syntactically valid code (or, in this case, syntactically valid OPath queries).
Given the potential complexity of a meaningful OPath query, are we going to need something analogous to CodeDOM to help us build them correctly? I'm not suggesting that we need something nearly as big or complex as CodeDOM -- just that it would be nice to have an API that consisted of a little bit more than StringBuild.Append().
CodeDOM, while being at times verbose and laborious, has a nice side effect: If you’re writing “pure” CodeDOM (i.e., no CodeSnippetExpressions), you can virtually guaranteed that the code generated from that CodeDOM graph will compile. Given the option, I’d rather debug compiler errors in my code generator than in my generated code, and CodeDOM buys me that. It would be nice to have something similar for OPath.
Here’s a potentially scary thought around generating OPath queries programmatically: Are we opening up a potential attack surface here, introducing the potential for “SQL injection”-like vulnerabilities into our object models?
