Skip to content
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

Untangle physical and logical layers #70

Closed
mmarx opened this issue Nov 23, 2022 · 0 comments
Closed

Untangle physical and logical layers #70

mmarx opened this issue Nov 23, 2022 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@mmarx
Copy link
Member

mmarx commented Nov 23, 2022

This is the meta-issue for the untanglement milestone, it holds the results of the discussion on 2022-11-23.

The physical layer should be self-sustaining (i.e., it could potentially be a stand-alone crate):

  • there should be a “Database Instance” on the physical layer that holds all relevant information (i.e., dictionaries for predicate names and for values, all tables, etc.); it should be able to answer questions about size and number of tables
  • tables are named (by Strings), where names are always set by the logical layer
  • all access to tables is exposed via table names
  • Iterators can be constructed from execution plans (plans need to be validated before execution, errors need to be propagated up)
  • the physical layer should not need knowledge about execution steps and delta tables
  • the schema of derived tables can be inferred from its constituents, for new tables, it is passed down from the logical layer
  • we want to support the following (distinct) primitive data types: u32, u64, f32, f64, “u32 with dictionary”, and “u64 with dictionary”
  • primitive data types can be joined iff they are (i) the exact same types (using, where applicable, the same dictionary), (ii) they are u32 and u64, or (iii) they are “u32 with dictionary” and “u64 with dictionary” and they have the same dictionary
  • association between table and dictionary is tracked by the database instance

The logical layer has:

  • the data model (which may need to be separated into a general and a rule-specific part)
  • a knowledge base (an instance of the logical data model)
  • the parser, which takes a (possibly empty) database instance, a (possibly empty) knowledge base and a program, and produces a database instance and a data model instance
  • a materialisation manager, which holds the database instance (and likely the data model instance) and, e.g., knows which delta tables are part of the materialisation of which tables
  • the materialisation manager directs the construction of Iterators, i.e., creates execution plans

IMG_20221123_115712

@mmarx mmarx added the enhancement New feature or request label Nov 23, 2022
mmarx added a commit that referenced this issue Nov 24, 2022
This reverts commit 910d36c.

As per discussion (#70), revert the string type.
@aannleax aannleax self-assigned this Nov 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

No branches or pull requests

2 participants