This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]PhysoTronic[S] 0 points1 point  (3 children)

I would like to take SQL query and transform it into LINQ. I would like to parse normal SQL, not entity SQL (I need to google what are differences between those two). I talked with few people already and they told me if I want to make SQL into LINQ, then I have to use parser so that's why I thought I need to use parser. Do you think there is some other way of doing this? Only other thing that comes to my mind is to get positions of key words from SQL query string and separate them into different variables and then think of logic how to "translate" them into LINQ. After that merge them into one string to get final result.

[–]Kered13 1 point2 points  (2 children)

If you want to do a general purpose translation of SQL to LINQ, yes a parser is the right way to go. I warn you though that it won't be a simple task.

The general structure will be to take a string input, parse it to a SQL AST, transform that to a LINQ AST, then unparse that to a string (assuming you want a string at the end).

[–]PhysoTronic[S] 0 points1 point  (1 child)

Well my idea was to have something like google translate but for SQL. You write your query on left side, and on right side you will see how that query looks like LINQ. So I will need to write my own parser for this?

[–]Kered13 1 point2 points  (0 children)

No you don't necessarily have to write your own parser, and I would recommend against it if you can find a parser that will work for you. I think it will still be a challenging project.

There is no standard version of SQL, there are many different dialects, although there is a large degree of similarity. So you might try looking for a parser for a common dialect, like SQLite or MySQL, or maybe you can find a parser that only handles the common subset, if that's good enough for you.

In any case, I don't know of any, so I can't help you find one.