retraction of an inexistent value of cardinality/one causes server panic

[spacegangster]

If a value isn't there, then retraction and its cardinality is one, then if I retract it – Declarative server panics. Not sure if it's a bug though.

reproduction below

; in core namespace
  (def schema
     :loan/epoch  (merge
                   (of-type :Number)
                   (input-semantics :db.semantics.cardinality/one)
                   (tx-time))})

; connect, submit schema then
  (exec! conn
         (transact db
                   [[:db/retract #uuid "1550c322-9111-44f8-a939-c53cee0d9774"
                     :loan/epoch 4]]))

Panic

 server git:(a1323c6) ✗ RUST_BACKTRACE=1 cargo run                                                                                                                   
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s                      
     Running `target/debug/declarative-server`                                                                                                                         
                                         
                                                                                                                                                                       
2thread 'worker thread 0' panicked at 'Received a retraction of a new key on a CardinalityOne attribute', /Users/spacegangster/clj/declarative-dataflow/src/operators/m
od.rs:76:29  

And I think now I don't understand what does cardinality means in this context.

[comnik]

Strictly speaking, this is not a bug. But even stricter speaking, the CardinalityOne story is not complete yet. The different cardinality's are actually write semantics to be enforced by 3DF. So CardinalityOne should be read as "last write wins", CardinalityMany means "distinct". As part of comnik/declarative-dataflow@a96eb70, they were actually renamed to reflect this.

Compare-and-swap is another input semantic, that we intend to support.

However right now, the last write wins implementation is a proof-of-concept. If you know, that your inputs will be well-formed (e.g. because Crux is already enforcing the right semantics), you should just use :db.semantics/raw.