-
Notifications
You must be signed in to change notification settings - Fork 25
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
Restrict functions which aren't allowed e.g. WHERE after LIMIT #128
Comments
I think it would be good if the consumer didn't have to think about the sequence and the query builder did the right thing always (resequence appropriately). Also the default sequence supported by sql is neither great nor intuitive imho. Eg. I almost always want to start my query chain with from so that in select/where I can get better autocompletion (Eg. FunSQL for julia). I also always forget whether limit comes first or order and it would be nice if I didn't have to bother about it. I am not sure how strongly you feel about aligning close to sql but I can take a stab at a PR if implicit resequencing is acceptable. |
Whatever you type in Mammoth gets translated to SQL 1 to 1 (more or less). The point is at least that this makes the order of functions important. For example, currently you may write
select(foo.id).from(foo).limit(2).where(foo.value.eq(123))
which would output a query with a limit first and where later which is obviously incorrect.Because we want to stick to SQL as close as possible, we don't want to sort the output tree to fix the query, instead, we want to give type hints to indicate something is not possible.
To achieve this, we can probably omit certain functions from the query if they can be considered invalid e.g. we cannot do a
.where()
anymore after a.limit()
as that would be invalid SQL. This makes Mammoth a little bit more type safe and the autocomplete really nice :).The text was updated successfully, but these errors were encountered: