Is the peer also on localhost? If not you need to change transactor host= to something the peer can reach

Transactors bind to host then write host and alt-host to storage. Peers then read those out of storage and attempt to connect to either of them. So you need host and/or alt-host to be routeable hosts or ips peers can connect to

Yes, the PostgreSQL server is separate, but everything else is running on localhost

I am not a datomic expert, but you could store your value as symbol? Otherwise you could save it as a ref and create the correct entity for each value (probability it has a lot memory disadvantage, but it would solve your problem).

It is not possible

You must represent it some other way

For cardinality one attributes, you can do a kind of tagged union thing. Make your polymorphic attr with a ref type; it’s value should be the attr with a specific variant attr

{:foo :fooString, :fooString “string”} for example

This makes nice query patterns

For cardinality many, if your type options are only scalar types maybe you can use fixed length heterogeneous tuples where only one value is non nil

Where I landed is I created three different entity schemas — one with a string attr, one with a float attr, one with an integer attr — then created an OR rule that will get the appropriate attribute value based on the entity, so that, given one of the three kinds of entities, I can uniformly access the value. It’s a little like a union type, and appears to work nicely.

Any drawbacks to this approach do you think?

You have to check three indexes, and you have to ensure only one is asserted at a time

Unless you mean there’s some other value on the entity that tells you which one it is? “One of the three kinds of entities” I’m not sure what that means

Let put more flesh on these bones.

;; Schema
#:db{:ident :foo-string/val
     :valueType :db.type/string
     :cardinality :db.cardinality/one}
#:db{:ident :foo-float/val
     :valueType :db.type/float
     :cardinality :db.cardinality/one}
#:db{:ident :foo-integer/val
     :valueType :db.type/long
     :cardinality :db.cardinality/one}

;; Rules
[[(val ?e ?v)
  [?e :foo-string/val ?v]]
 [(val ?e ?v)
  [?e :foo-float/val ?v]]
 [(val ?e ?v)
  [?e :foo-integer/val ?v]]]

Won’t it consult one index only?

I'm also interested in learning more about profiling the performance of my rule — are you familiar with any recs or literature on how to do that?

Yeah that will have the two downsides I talked about

3 index lookups and its structurally possible to have more than one asserted on same entity

What I was suggesting would give a query pattern like this

[?e :foo ?foo-attr] [?e ?foo-attr ?foo-val]

Where ?foo-attr is one of your foo-*/val attrs

(A ref to the attr not a keyword)

Thanks I reckon a join is less expensive in Datomic than an index lookup?

(In my case I’m not very concerned about the possibility of more than one assertion on the entity, but I am concerned about slowness.)

It’s not join vs index lookup, it’s 1-2 lookups vs 3 where at least two of them are misses

If your db still fits in object cache this is unlikely to matter

🙏:skin-tone-2: