mentat/query-algebrizer
Richard Newman 6797a606b5 Preliminary work for vocabulary management. r=emily,nalexander
Pre: export AttributeBuilder from mentat_db.
Pre: fix module-level comment for tx/src/entities.rs.
Pre: rename some `to_` conversions to `into_`.
Pre: make AttributeBuilder::unique less verbose.
Pre: split out a HasSchema trait to abstract over Schema.
Pre: rename SchemaMap/schema_map to AttributeMap/attribute_map.
Pre: TypedValue/NamespacedKeyword conversions.
Pre: turn Unique and ValueType into TypedValue::Keyword.
Pre: export IntoResult.
Pre: export NamespacedKeyword from mentat_core.
Pre: use intern_set in tx.
Pre: add InternSet::len.
Pre: comment gardening.
Pre: remove inaccurate TODO from TxReport comment.
2018-01-23 08:25:32 -08:00
..
src Preliminary work for vocabulary management. r=emily,nalexander 2018-01-23 08:25:32 -08:00
tests Preliminary work for vocabulary management. r=emily,nalexander 2018-01-23 08:25:32 -08: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.