Linq for Salesforce "SQL" Provider

Question

So, I have this new project. My company uses the SalesForce.com cloud to store daily operations information. My task is to write a new application that, among other things, will more easily integrate CRUD operations of this data with the existing functionality of the application.

The heart of the Salesforce WSDL API is the set of web-based query () methods that accept a query command as a string. The query syntax is SQL-ish, but not quite (they call it SOQL). I am not a fan of magic strings, so I would like to use Linq in the code base and analyze IQueryable in the SOQL query that I need in the shell for this service. This is certainly possible (L2E, L2Sql), but I would like to know if there is a shortcut, because if I say that it takes more than one or two days to collapse, I will be “encouraged” to find another method (most likely a method for each general purpose request, which was the method used in older applications). If I manage to make a general-purpose SOQL analyzer, we can use it in several other applications, and I will become a hero. Even if I make a simple one that only supports certain query structures, this will go a long way by allowing me to continue the current Linq-y project, and I can expand it in my free time.

Here are the options I see:

• It looks more complicated for the existing Linq2SOQL provider (my Google-fu does not bother me, otherwise it just doesn’t, the only .NET shell mentions Linq as pleasant for itself).
• Building an expression tree parser. It should support at least the Select and Where calls and must either parse lambdas or manipulate their methods to get the necessary operations and forecasts. This seems to be a fairly large-scale task, but, as I said, it is certainly possible.
• Wrap the service in Linq2Sql or a similar existing Linq provider, which will allow me to extract a string with a sufficient number of queries, polish it and pass it to the service. There should be dozens (although none of them come in, AFAIK).
• Call Expression.ToString () (or Expression.DebugView) and process this line to create a SOQL query. It will be fragile, it will be ugly (backstage), and it will only support what I am clearly looking for, but it will provide a rudimentary translation that will allow me to move on.

What do you guys think? Is creating a Linq parser more than a two-day task for one guy? Could this be a solution related to an existing Linq provider? Would it be terrible to split the expression string and build my query this way?

EDIT: Thanks to Kirk for grounding. I took a little look at what I would need to do even for the basic SOQL analyzer, and this goes beyond the fact that I get a working application code written on any possible chart. For example, I need to create a selection list either from the Select () method lambda, or by default from all the known columns from my WSDL object, tasks that I didn’t even think about (I focused more on parsing Where), I am sure there are there are many other “unknown unknowns” that can turn this into a pretty big deal. I found some links that show the basics of writing a Linq provider, and although they all try to make it simple, it just won't be feasible in time right now. I will now create my repository using named methods that encapsulate named queries (a constant class of formatted query strings should reduce the number of scratches on the head during maintenance). Not perfect, but much more feasible. If and when the Linq2SOQL provider goes underground, both internally and open source, we can reorganize.

For others looking for Linq provider links, here are the useful links I found:

• Creating a Linq Provider
• Walkthrough: Creating an IQueryable LINQ Provider
• Linq: Creating IQueryable Provider Series - in 17 Parts! <- this one, although long and involved, has many real in-depth explanations and is good for "first graders."

Answer 1

Let them take one at a time:

Look harder for the existing Linq2SOQL provider (my Google-fu can't get me here, otherwise it's just not there, the only .NET shell mentions Linq as pleasant for itself).

Yes, I doubt that it already exists, but I hope you can find it.

Building an expression tree parser. It should support at least the Select and Where calls and must either parse lambdas or manipulate their methods to get the necessary operations and forecasts. This seems to be a fairly large-scale task, but, as I said, it is certainly possible.

This is absolutely the way to go if you are really serious about it in the long run.

Wrap the service in Linq2Sql or a similar existing Linq provider, which will allow me to extract the query string close enough, polish it and pass it to the service. There should be dozens (although none of them come in, AFAIK).

What do you mean by the word "drop in"? You can easily get SQL directly from L2S.

Call Expression.ToString () (or Expression.DebugView) and manipulate this line to create a SOQL query. It will be fragile, it will be ugly (behind the scenes), and it will only support what I am clearly looking for, but it will provide a rudimentary translation that will allow me to move on.

I would strongly discourage you from this approach, because at least it will be at least as difficult as the correct syntactical decomposition of expression trees. In any case, to use this, you first need to put the parsed strings in a suitable object model - that is, the existing expression trees that you start with.

---

Indeed, you should consider creating a query provider and doing it right. I think that two days are a little stretched, although in order to make something work even in a primitive sense, although it is possible. IMO, you should explore it at home and play with it so that you have some familiarity with the basic items and parts. Then you are unlikely to be able to get a few useful requests in two days.

Honestly, the full implementation of such a project is really in the sphere of several weeks, if not months, not days.

If this is too much, you can consider option 3. I am not an expert in SOQL, so I don’t know what kind of work will be involved in converting ordinary SQL queries to SOQL queries. If you find this more likely algorithmic and reliable, this might be the way to go.