mentat/query-algebrizer
Richard Newman e21156a754
Implement simple pull expressions (#638) r=nalexander
* Refactor AttributeCache populator code for use from pull.

* Pre: add to_value_rc to Cloned.

* Pre: add From<StructuredMap> for Binding.

* Pre: clarify Store::open_empty.

* Pre: StructuredMap cleanup.

* Pre: clean up a doc test.

* Split projector crate. Pass schema to projector.

* CLI support for printing bindings.

* Add and use ConjoiningClauses::derive_types_from_find_spec.

* Define pull types.

* Implement pull on top of the attribute cache layer.

* Add pull support to the projector.

* Parse pull expressions.

* Add simple pull support to connection objects.

* Tests for pull.

* Compile with Rust 1.25.

The only choice involved in this commit is that of replacing the
anonymous lifetime '_ with a named lifetime for the cache; since we're
accepting a Known, which includes the cache in question, I think it's
clear that we expect the function to apply to any given cache
lifetime.

* Review comments.

* Bail on unnamed attribute.

* Make assert_parse_failure_contains safe to use.

* Rework query parser to report better errors for pull.

* Test for mixed wildcard and simple attribute.
2018-05-04 12:56:00 -07:00
..
src Implement simple pull expressions (#638) r=nalexander 2018-05-04 12:56:00 -07:00
tests Simple aggregates. (#584) r=emily 2018-03-12 15:18:50 -07:00
Cargo.toml Partial work from simple aggregates work (#497) r=nalexander 2017-11-30 15:02:07 -08:00
README.md Partly flesh out query algebrizer. (#243) r=nalexander 2017-02-15 16:10:59 -08:00

This crate turns a parsed query, as defined by the query crate and produced by the query-parser crate, into an algebrized tree, also called a query processor tree.

This is something of a wooly definition: a query algebrizer in a traditional relational database is the component that combines the schema — including column type constraints — with the query, resolving names and that sort of thing. Much of that work is unnecessary in our model; for example, we don't need to resolve column aliases, deal with table names, or that sort of thing. But the similarity is strong enough to give us the name of this crate.

The result of this process is traditionally handed to the query optimizer to yield an execution plan. In our case the execution plan is deterministically derived from the algebrized tree, and the real optimization (such as it is) takes place within the underlying SQLite database.