Expand internal representation of an Attribute to represent idea of absence #285

New issue

Open

opened 2020-08-06 16:57:52 +00:00 by gburd · 0 comments

gburd commented

2020-08-06 16:57:52 +00:00

(Migrated from github.com)

Vague problem statement:

To better support of retracting schema (as part of the timelines work, see #783), we need to have more knowledge than is currently available in-memory. Mentat's definition of a schema attribute currently does not allow us to determine if a particular schema attribute is actually present in the datoms, or if it's a derived default value.

E.g. if we did not assert [:db/add 100 :db/index true], then the index field in the Attribute struct for entid=100 will be false. From the point of view of schema retraction, meaning of that false value is not the same as if actually asserted that [:db/add 100 :db/index false].

Schema retraction rule 1) If :db/ident is being retracted, and that entity is a schema attribute - that is, it also has :db/valueType and :db/cardinality - these datoms (and any optional ones) must also be retracted. (why leave around dangling schema attributes?)
Schema retraction rule 2) if either of the required schema attribute entities are being retracted (:db/valueType, :db/cardinality), then all of the required schema attributes must be retracted, as well as a corresponding :db/ident.

However, currently we can't tell by just inspecting an AttributeMap that a given entity has these attributes. And so to enforce rule 1, we must read datoms from disk.

Implementation of schema retraction introduced in #783 punts on rule 1, and only enforces rule 2.

Vague problem statement: To better support of retracting schema (as part of the timelines work, see #783), we need to have more knowledge than is currently available in-memory. Mentat's definition of a schema attribute currently does not allow us to determine if a particular schema attribute is actually present in the datoms, or if it's a derived default value. E.g. if we did not assert `[:db/add 100 :db/index true]`, then the `index` field in the `Attribute` struct for entid=100 will be `false`. From the point of view of schema retraction, meaning of that `false` value is not the same as if actually asserted that `[:db/add 100 :db/index false]`. - Schema retraction rule 1) If `:db/ident` is being retracted, and that entity is a schema attribute - that is, it also has `:db/valueType` and `:db/cardinality` - these datoms (and any optional ones) must also be retracted. (why leave around dangling schema attributes?) - Schema retraction rule 2) if either of the required schema attribute entities are being retracted (`:db/valueType`, `:db/cardinality`), then all of the required schema attributes must be retracted, as well as a corresponding `:db/ident`. However, currently we can't tell by just inspecting an `AttributeMap` that a given entity has these attributes. And so to enforce rule 1, we must read `datoms` from disk. Implementation of schema retraction introduced in #783 punts on rule 1, and only enforces rule 2.