WS258 schema issue :splice-confirmation/false

[sibyl229]

Hi @mgrbyte I think you probably intended to fix the attribute :splice-confirmation/false at some point, because I noticed it's gone from the generated schema for WS258. I'm happy you are trying to fix this, because false as a Symbol won't survive serialization to edn and back, which I'm thinking of doing for the converted GraphQL schema.

But strangely, the same schema is showing up in the live 258 database. Here is what the schema query shows:

[:find ?e ?ident
:in $ ?ns
:where
[?e :db/ident ?ident]
[(namespace ?ident) ?ns]
]

input ?ns is splice-confirmation

[mgrbyte]

@sibyl229 The :splice-confirmation ACeDB hash-model #Splice_confirmation has been removed in WS259 due to it being unused - I don't believe any data will be found in WS258 against that component model. :feature-data is in the same category as :homol-data in that the corresponding Datomic idents for ACeDB models exist, but are present only as: "stubs to support capture of parent and mapping" (search for stubs in the annotated models, and see that all references to the ?Feature_data and ?Homol_data stub ACeDB classes have been commented out in XREFs to other models (e.g ?Sequence)

You may be interested in the comment above the said model block in the source annotated models. (Assuming you're trying work with :feature-data?)

Regarding your assertion about false not working with EDN serialisation, that's not correct:

pseudoace.cli> (require '[clojure.edn :as edn])
nil
pseudoace.cli> (edn/read-string "{:x false}")
{:x false}

[sibyl229]

Thanks a lot @mgrbyte for the clarification!

I realized from what you said that it's not a problem with the Datomic schema, but how a field schema is handled in my converted GraphQL schema. And I really shouldn't have tried to serialize (to edn) a data structure produced by an external library =P

(a bit of random info) About the edn serialization, what I started with was the field name (symbol "false") rather than false (the boolean), where the distinction can't be preserved when writing to string. The library author decided to use symbol to represent a field name rather than a keyword, because (I imagine) the field is a function, for example is able to take arguments.