provisdom / spectomic Goto Github PK

I'm not really sure if it's worth the trouble to do something about this, but I thought I'd report it since it is somewhat normal usage. I've worked around it by writing the spec less generically and using more of them, but I've got a spec described as;

(s/def :dp.attr/dt-kw (s/and :dp.attr/keyword #(kw-in-ns-hierarchy? % "dp.dt")))

Where the predicate function is,

(defn kw-in-ns-hierarchy? "Takes a keyword and a partial or complete namespace and responds true if the keyword is in the hierarchy." [kw, ns-partial-string] (clojure.string/starts-with? (namespace kw) ns-partial-string))

Meaning the keyword could be anything that starts with :dp.dt. This blows up the generation stage.

=> Execution error (ExceptionInfo) at provisdom.spectomic.core/find-type-via-generation$fn (core.clj:79). Couldn't satisfy such-that predicate after 100 tries.

This may be a hard limitation, no biggie over here. Just thought you should know. I'm enjoying having the library in my workflow. Thanks for sharing!

A couple of potential issues exist when inferring ref attributes simply via the predicate map?. One is that it implies some semantics about how you're handling the map if specified in transaction data, because map? does not require the existence of a :db/id key or an attribute indicating identity. One might assume, for example, if :db/id is absent then a new entity will be created. But that will be application-specific.

The other issue is that many use-cases call for an actual entity ID as opposed to a map. And though you could infer a ref in some cases (tempid is an instance of datomic.db.DbId, lookup ref is a tuple of keyword? and any?), I don't know how you disambiguate between longs and entity IDs, or keywords and :db/ident.

The schema override feature basically solves this, let's you explicitly denote the attribute as a ref. If we want the feature to infer ref attributes, maybe the user could supply a predicate reflecting their application semantics (e.g. if map? was appropriate for their app, then they could specify map? as the predicate). It might be nice, just because it makes those semantics explicit in the spec. You'd still have the potential ambiguous cases, but those probably just have to be handled by the override.

Sometimes it will be useful to explicitly specify :db/valueType, e.g. if for some reason a predicate can't generate appropriate values. If :db/type is specified, just take it as-is and don't perform type inference.

Currently, if a spec if defined using s/merge or s/keys i.e. a composite spec, generating datomic schema out of it using spectomic.core/datomic-schema does not generate schema for all the individual specs it is made of.
If this is implemented, it will alleviate the pain of individually populating the spec vector to be fed to the spectomic.core/datomic-schema function.
Overriding of the individual specs' schemas should still be possible.

The code block:

(spectomic/datomic-schema [[:entity/id {:db/unique :db.unique/identity :db/index true}] :user/name :user/favorite-foods])

Does not have the statement user/orders in it. So it should become:

(spectomic/datomic-schema [[:entity/id {:db/unique :db.unique/identity :db/index true}] :user/name :user/favorite-foods :user/orders])

I was going through the readme and I found something confusing. It might be a typo or something I
am not quite getting. It would make sense to me if the first outlined item in my image below is more like (s/def ::order (s/keys :req [:entity/id :order/name]))

I have not run this myself to verify. When I have time later I'll try.

When including schema attributes in the form [::spec {db/...}], should check that the vector has only two elements, first is a spec, second is a map, etc.