hyperfiddle-2020
hyperfiddle-2020 copied to clipboard
hyperfiddle
Value 190 is not a valid :float for attribute :record/weight
This is line of fire for a consulting lead who asked me to replicate a trivial spreadsheet, i had to add .01 to make these parse as floats:
This can be done at the last second (d/with db-with {:tx-data (coerce-tx tx schema)})
But the client has the schema, cant it send up correct values in the first place?
No, Javascript can't tell the difference i forgot. Internal representation of number and float is the same. Can it happen at the point of serializing to transit? This theoretically could happen but Transit would need to deeply understand [:db/add e a v] and know that v is typed by a
[:db/add "hyperfiddle.tempid-525511487" :db/ident :dustingetz/weight]
[:db/add "hyperfiddle.tempid-525511487" :db/cardinality :db.cardinality/one]
[:db/add "hyperfiddle.tempid-525511487" :db/valueType :db.type/float]
Ok this is fucked ... to coerce the tx accounting for expected valueTypes ... you need to know the schema... which means a schema query already happened earlier in the request... but what if this is the request for the schema (bootstrapping the request). You need a pre-tx value of the schema
Consider the following user-stage + ide-stage
Each side's first query is a schema query and that schema query has the stage applied and that stage needs normalizing despite not having the schema yet
Fix 1 is to throw a hardcoded d/q in there Fix 2 is to somehow get the client to send the right values up in the first place
Current thinking: Hydrate the schemas twice, first time without the stage, shove them into partition, then run this code as usual
