Private Preview - features may change without notice
GramSpec
Architecture Spec API Reference Pricing About
Start free

Keep it true · 11

More than one model

The answers to “do we have to model everything before we get anything?” and “our users never know which dataset to pick.” Nobody has to put a whole database into one model. They model the corner that matters, get answers there, and a question that crosses two models draws on both.

Several small models over one database. A question is asked in Reason without picking a model, Reason picks the model that can answer, widens to a neighbouring model when the question needs it, runs on the one database they both describe, and says which model it answered from.GRAMSPECYOUR DATASomeone with aquestionReasonasked without picking amodelA model of salesnot needed this timeA model ofpurchasingA model of stockOne databaseread-only12345 Several small models over one database. A question is asked in Reason without picking a model, Reason picks the model that can answer, widens to a neighbouring model when the question needs it, runs on the one database they both describe, and says which model it answered from.GRAMSPECYOUR DATASomeonewith aquestionReasonasked withoutpicking a modelA model ofsalesA model ofpurchasingA model ofstockOne databaseread-only12345
One flow. The models are never merged; they are put together for one question and let go.
  1. Someone asks a question without picking a model. Reason says, under the box they type in, how much is in reach: one model they chose, or every model they have.
  2. Reason picks the model that can answer. It is shown what each model covers, table by table, and picking a model also decides which database the query will run on.
  3. When the question needs a neighbouring model, the two are put together. A model on the same database that covers what is missing is brought in for this question. A table both describe becomes one, and everything else is added. Where they disagree about a rule, the weaker one is taken and that is said.
  4. The query runs on the one database they both describe. If any model that should be part of the answer cannot be loaded, the whole question fails loudly. It is never answered from the part that is left.
  5. The answer says where it came from. Each finding names the model it was answered from and the connection it ran on.

Nothing is merged or stored. Each model stays small, checkable and owned by whoever keeps it. What is put together for a question is let go when the question is answered.