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

New issue

Open

opened 2020-08-06 16:13:27 +00:00 by gburd · 1 comment

gburd commented

2020-08-06 16:13:27 +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.

Original by @grigoryk

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. Original by @grigoryk

gburd commented

2020-08-06 16:13:29 +00:00

(Migrated from github.com)

Rule 1 assumes that every attribute must be named by ident. In general we discourage retracting idents (it's kinda scary and meaningless to reassign an ident to a different entity), so…

Rule 2: it would be risky to retract the ident, and bear in mind that you can just retract a single attribute and then assert a new value for it in the same transaction…

What you're talking about here is a kind of consistency: that given a set of schema-required attributes A, this badly written predicate logic holds:

∀ a ∈ A, s ∙ asserted(s, a, _) ⇒ ∀ a' ∈ A ∙ asserted(s, a', _)

In english: for all entities in the union of the domains of required schema attributes, every required schema attribute is present on each entity. You might benefit from thinking about it in those terms.

Original by @rnewman

Rule 1 assumes that every attribute must be named by ident. In general we discourage retracting idents (it's kinda scary and meaningless to reassign an ident to a different entity), so… Rule 2: it would be risky to retract the ident, and bear in mind that you can just retract a single attribute and then assert a new value for it in the same transaction… What you're talking about here is a kind of consistency: that given a set of schema-required attributes *A*, this badly written predicate logic holds: ``` ∀ a ∈ A, s ∙ asserted(s, a, _) ⇒ ∀ a' ∈ A ∙ asserted(s, a', _) ``` In english: for all entities in the union of the domains of required schema attributes, every required schema attribute is present on each entity. You might benefit from thinking about it in those terms. Original by @rnewman