Fork me on GitHub
#datomic
<
2020-07-18
>
zilti16:07:39

I fail to connect to my freshly set up datomic-pro. I get this error, which seems to be the usual one:

zilti16:07:19

Datomic itself seems to have started fine: System started datomic:sql://<DB-NAME>?jdbc:, you may need to change the user and password parameters to work with your jdbc driver

zilti16:07:55

In the transactor config, I've set protocol to sql, host to 127.0.0.1 and port to 4334. I've added the license key and set the sql-url, -user, -password and -driver-class.

favila18:07:35

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

favila18:07:43

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

zilti12:07:49

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

dregre22:07:56

Noobie question: Is it possible to create a Datomic schema where a value has an expected type of any, or at least a union type? I'd like a value to be either a string, integer, or float.

dregre22:07:56

Noobie question: Is it possible to create a Datomic schema where a value has an expected type of any, or at least a union type? I'd like a value to be either a string, integer, or float.

David Pham08:07:10

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).

favila13:07:31

It is not possible

favila13:07:47

You must represent it some other way

favila13:07:50

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

favila13:07:43

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

favila13:07:59

This makes nice query patterns

favila13:07:50

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

dregre16:07:32

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.

dregre16:07:13

Any drawbacks to this approach do you think?

favila18:07:25

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

favila18:07:24

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

dregre19:07:03

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]]]

dregre19:07:38

Won’t it consult one index only?

dregre19:07:00

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?

favila00:07:11

Yeah that will have the two downsides I talked about

favila00:07:48

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

favila00:07:11

What I was suggesting would give a query pattern like this

favila00:07:30

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

favila00:07:23

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

favila00:07:26

(A ref to the attr not a keyword)

dregre01:07:45

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

dregre01:07:06

(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.)

favila12:07:26

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

favila12:07:53

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

dregre12:07:19

🙏:skin-tone-2: