datomic

Ask questions on the official Q&A site at https://ask.datomic.com!
onetom 2020-11-23T04:14:05.472100Z

Our Datomic Cloud subcription is not showing up on the AWS Marketplace / Manage subscriptions https://console.aws.amazon.com/marketplace/home?region=ap-southeast-1#/subscriptions is that expected? I see other subscriptions though from Container / Machine Image and CloudFormation categories...

tatut 2020-11-23T06:52:02.472400Z

downgrading worked

tatut 2020-11-23T06:53:39.473700Z

the analytics doesn’t seem to work if db-name contains a dash - character, I’m getting Query 20201123_062629_00002_8pm43 failed: Expected string for :db-name when trying a query, but it works if db name contains only characters

joshkh 2020-11-23T12:33:18.480600Z

huh. for what it's worth, i'm running analytics on a db with a dash in its name without an issue

tatut 2020-11-23T13:40:23.482700Z

good to know, maybe it has some other issue, or it was a presto cli problem

tatut 2020-11-23T06:55:10.473800Z

I had a test db that was named project-2020-11-13 with a date and it didn’t work but the db named just project worked fine

2020-11-23T09:36:34.477700Z

I have relation when order has customet attribute and can access customer via: [?o :order/customer ?c] The same way I can access order if I have query of customers. Also I can use get-else when order has no customer. But how can I filter customers without orders? (not [?o :order/customer ?c]) gives an error

:db.error/insufficient-binding [?o] not bound in not clause: (not-join [?o ?c] [?o :order/customer ?c])

2020-11-23T09:58:00.478500Z

Seems that this way works:

(not-join [?c]
[?o :order/customer ?c])

2020-11-23T10:00:02.479900Z

And also seems that not is a sugar on not-join, allowing not to set bindings explicitly and manually

2020-11-23T10:10:31.480500Z

Hmm, seems that (not [_ :order/customer ?c]) also works

joshkh 2020-11-23T12:33:18.480600Z

huh. for what it's worth, i'm running analytics on a db with a dash in its name without an issue

kschltz 2020-11-23T12:41:28.480800Z

@ivana it seems to me that issue lies entirely in the binding

favila 2020-11-23T13:34:04.481Z

they shouldn’t, and I thought they could not

favila 2020-11-23T13:34:12.481200Z

if you read the docs, they make no mention of this

favila 2020-11-23T13:34:44.481400Z

also conceptually, it’s bad: ref values are supposed to be managed by datomic--this is no different than putting a long into a tuple

favila 2020-11-23T13:35:27.481600Z

with composite tuples, it knows what assertion it’s denormalized from; here, there is no support. and you can’t use lookup refs or keywords or tempids to reference these

favila 2020-11-23T13:36:33.481800Z

docs: https://docs.datomic.com/on-prem/schema.html#tuples

favila 2020-11-23T13:37:33.482100Z

I’m wrong though, :db.type/ref is lised as a scalar type

favila 2020-11-23T13:38:04.482300Z

I am pretty sure it wasn’t the last time I read this--maybe a change? Anyway, it still seems like a bad idea

favila 2020-11-23T13:38:28.482500Z

but if you really need to do it, queries needs to be defensive against nils

tatut 2020-11-23T13:40:23.482700Z

good to know, maybe it has some other issue, or it was a presto cli problem

favila 2020-11-23T13:41:05.482900Z

[(!= ?x nil)] immediately might work, [(some? ?x)] should definitely work.

henrik 2020-11-23T13:59:17.483700Z

[Cloud/Ions] Does all deps have to be under :deps, or can aliases be specified when pushing?

henrik 2020-11-24T13:56:27.492200Z

Ah, too bad. Had a good composable thing going, but I’m going to have to dump it all in :deps then. 🤷

souenzzo 2020-11-23T20:53:53.484Z

no, AFIK, you can specify an alias As I dig (not documented or explained by anyone): the datomic-cloud instance will download your code, open your deps.edn, take the :deps make and decide which deps it will use (something like, it do not use #tools-deps or at least, not as a simple command line)