New mode for compiling SQL queries from DDlog's query syntax

[netj]

ddlog query for implementing deepdive query in HazyResearch/deepdive#476

[feiranwang]

The order_by annotation takes a different form from other annotations. Looks good other than this.

[netj]

Not sure what you mean by different form? That it parses with the general annotation parser also used for schema annotations? I think the rest of annotations in the future should be parsed in that way, maybe except @weight and @label that take general expressions.

[feiranwang]

By different form I mean there is a @order_by num_candidates, and I was assuming something like @order_by(num_candidates). Maybe the former is also allowed in the general annotations?

[netj]

Those two are separate: an annotation (@order_by) and an expression (num_candidates). I extended the grammar (at least for the query rules) to accept optional annotations before each head term expression. See my examples in HazyResearch/deepdive#476. So @foo @order_by @bar(123,456) num_candidates, @bar(78,90) another_var ?- ... is also valid.

Query rules are special case and the first won't get confused with rule annotations. For normal rules (in the future when we extend the grammar), I think there won't be ambiguity because the head name and a parenthesis will also be there before each head term expression, right?

There's a limitation that you can't hide the order by column of course but I think people will like to just prefix a column with an annotation rather than repeating a variable or expression to simply order by. If we think people will frequently want to drop the ordering column, we should go ahead and support @order_by for normal rules as well, so a temporary table/view can be defined first then projected out in the actual query.

[feiranwang]

I see. Thanks for the explanation!

On Feb 1, 2016, at 2:04 AM, Jaeho Shin notifications@github.com wrote:

Those two are separate: an annotation (@order_by) and an expression (num_candidates). I extended the grammar (at least for the query rules) to accept optional annotations before each head term expression. See my examples in HazyResearch/deepdive#476. So @foo @order_by @bar(123,456) num_candidates, @bar(78,90) another_var ?- ... is also valid.

Query rules are special case and the first won't get confused with rule annotations. For normal rules (in the future when we extend the grammar), I think there won't be ambiguity because the head name and a parenthesis will also be there before each head term expression, right?

There's a limitation that you can't hide the order by column of course but I think people will like to just prefix a column with an annotation rather than repeating a variable or expression to simply order by. If we think people will frequently want to drop the ordering column, we should go ahead and support @order_by for normal rules as well, so a temporary table/view can be defined first then projected out in the actual query.

— Reply to this email directly or view it on GitHub.

[netj]

(I'm resolving the merge conflicts now btw)

[netj]

Oops the lower coverage shows some dead code and sloppy merge of mine. Will push another commit. Please merge later!

[netj]

Okay ready to merge. Coverage drop seems negligible.

[bar]

@netj WAT?