Skip to content

Instantly share code, notes, and snippets.

@yeesian
Last active August 23, 2016 20:17
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save yeesian/e7d1293d464703a463d1abde47f508b4 to your computer and use it in GitHub Desktop.
Save yeesian/e7d1293d464703a463d1abde47f508b4 to your computer and use it in GitHub Desktop.

The Query System

QuerySyntax

We compose valid syntax using the following components:

The Pipe: source |> verb(...)

  • where "source" must be a valid source
  • and "verb" must be a valid verb

Valid Source

Can be either

  • source, where source must be a valid identifier (subject to possibly more conditions), or
  • (source |> verb1(...) |> ...) (i.e. a source that has been piped through a sequence of verbs
  • ... (e.g. :table as a placeholder for a table)

Valid identifiers

- prefer lowercase names (i.e. lowercasename instead of LowerCaseName, etc)
- allow underscores (e.g. lower_case_name and lowercasename are both valid)
- can be prefixed by a table name (e.g. `table.columnname` and `columnname` are both valid)
- should maybe follow a reference, e.g. https://msdn.microsoft.com/en-us/library/ms175874.aspx#Anchor_1

Valid verbs

- should support (API functions that registered verbs will need to implement)
- convention: lowercase english verbs, allow underscore, etc
- each verb should be called like the following: `verb(arg1, arg2, ..., keyword1(kw1arg1, kw1arg2, ...), keyword2(kw2arg1, kw2arg2, ...))` where
    - keywords should satisfy the following rules to be a valid name (..., might follow mostly the same rules as verbs)
    - arguments e.g. `arg1, arg2, kw1arg1, ..., kw2arg2, ...` will have to satisfy the conditions for being a valid expression

Valid Expressions

can be either a
- valid identifier (see point 2)
- valid function call (see point 6)
- valid ...

Valid Functions

- conventions: functions should satisfy the following rules to be a valid name (..., e.g. lowercase english verbs, allow underscore, etc)
- should satisfy ... rules

QueryComponents

QueryNodes

type CustomNode <: AbstractQuery.AbstractQueryNode
    source
    args
    [possibly: parameters, helpers, ...]
end

where

  • source is ...
  • args is ...
  • etc is ... (environment, helpers, etc)

to register it:

AbstractQuery.QUERYNODE[:customverb] = CustomNode

QueryFunctions

(not the responsibility of the specification to dictate)

  • User-Defined Function (UDF): maps a tuple to a “scalar”.
  • User-Defined Aggregation Function (UDAF): translates a whole table into a single “scalar”.
  • User-Defined Table Function (UDTF): expands a tuple into a table.

How should users register their functions?

Some examples

Ongoing Considerations

Interpolation

- [ ] verbs?
- [ ] functions?
- [ ] keywords?
- [x] expressions

Prepared queries/statements

- [ ]

Resolution for extensions with clashing names (if any)?

bleargh (first-come-first-serve? module.verb?) Up to the individual backends how they should interpret the query expressions/object

Construction of aliases/views/etc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment