-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document SQL syntax used #142
Comments
That is correct — there is no such documentation at the moment. Since this is a research prototype, we sort of just support what the implementation supports, and it's not quite that clearly defined :) In general, most straightforward SQL statements should work, including most aggregations, order+limit, projections, filters, and joins where the join clause is a single column equality. |
I think there are two questions here:
Concretely: what can I put into So documentation here is very limited. Maybe this is another reason why it would be useful to switch to sqlparser-rs. Because then you can just delegate the syntax questions to it. Then probably MySQL adapter would have to be changed a bit so that queries are rewritten from MySQL to internal SQL language. I think that it is visible that current syntax is as-is to make it easier to make MySQL support. But that is also a bit breaking the abstraction. BTW, in my Rust client applications, do I have to use SQL syntax? Or could I create tables by calling some Rust methods? Because the main motivation for me for this issue was that it looks like when I am building a Rust client application I still have to use SQL (and which SQL) to interact with Noria. It is not that Rust client application would provide programmatic API and then MySQL adapter would map from SQL to that API. Rust client library is using SQL as well. That was a surprise to me. And then it also made it unclear what is this SQL syntax I should be using. Because in examples is not just SQL but also some additional special cases like |
Ah, yes, you're right, there is also no documentation of the high-level details about queries. In general though, it is just standard SQL; that's why we didn't think to do it. There are some extensions (such as the As for the Rust interface, the SQL you use to give recipes there should be exactly the same as the MySQL shim. The way to think about this is probably that Noria itself uses SQL, and that the shim is just a way to be compatible with the MySQL wire protocol. We could, in theory, provide a lower-level interface for manually constructing Noria dataflow, but that's pretty difficult to do well since the dataflow is subject to a number of somewhat finicky layout rules that we would somehow need to enforce for user-specified dataflow as well. Our multi-query optimization also relies on SQL, so a manually specified graph would not get the advantages of cross-query combination. |
@ms705 I agree with @mitar that we should documented how Noria's SQL syntax translates to Noria's concepts. For example, things like the |
Moving to Independently of this, we'll add some documentation on how the |
BTW, do you care about Moving to |
The MySQL adapter also uses our custom parser at the moment; it would need to likewise move to
|
OK, but I think it will be easier to add to You are not really passing directly SQL queries to MySQL anyway, no? |
That's correct, |
So then I am not sure why it could not then work if Noria would use internally |
It could -- if the parser (whichever is used) supported parameters in |
OK, we then understand each other. Good. :-) I will see if and when I will have time to contribute PRs to this and other ideas I have brought up. I would love to, but at the moment am I a bit swamped with other things. Anyway, it is good to know what should be done. Thanks. |
Meaning |
@HenkPoley Correct :) |
I could not find documentation for which exactly SQL syntax is being used/supported?
The text was updated successfully, but these errors were encountered: