Ask questions on the official Q&A site at https://ask.datomic.com!
steveb8n 2020-09-25T02:03:34.005900Z

@joshkh exactly! despite the fact that we might not need backup/recovery, in an enterprise sales cycle this can be a real problem. Even worse if it’s an RFP situation because the prospect writing the RFP might consider common DR techniques to be a must have. It doesn’t matter that we can explain it away, the internal politicians in the customer can simply use this as a battering ram to avoid choosing our product. It’s not always a technical question: I hope one day Cognitect will provide an answer for export so that Datomic Cloud can be used without this risk in the sales cycle. @marshall any comments on this?

steveb8n 2020-09-25T02:06:27.006100Z

what’s interesting is that Datomic provides DR features that other dbs cannot e.g. you can recover a single tenants data to any point in time, even in a multi-tenant system. Update in-place dbs cannot do this. So we are technically superior for DR. But that doesn’t always work in enterprise sales.

Nassin 2020-09-25T02:09:44.006300Z

Curious, why does your application relies on entiti ids ?

tatut 2020-09-25T05:00:31.006500Z

DR is also to protect against human error, customers want to have a backup file stored in a completely different AWS account S3 bucket… or even have it downloaded to their own infastructure

tatut 2020-09-25T05:01:27.006700Z

and when you have backups you need to be able to restore from them… now we’ve rolled our own and fixed some mistakes we’ve made in relying too much on :db/id values

steveb8n 2020-09-25T06:22:22.007Z

that’s true. you could accidentally delete your Datomic s3 bucket and then you’d be finished! goodbye biz 😞

steveb8n 2020-09-25T06:23:40.007200Z

I wonder if some kind of s3 level backup would be supported by Datomic to guard against this?

stuarthalloway 2020-09-25T19:31:29.007600Z

@joshkh @steveb8n We hear you and working on things in this area.

joshkh 2020-09-25T19:33:03.008100Z

cheers. i know that we're in good hands. 🙂

jaret 2020-09-25T19:34:47.009100Z

^ New release of Dev Tools provides dev-tools via Cognitect maven repo!

jaret 2020-09-25T19:35:41.009300Z

It's on the list 🙂. I'll try to remember to poke you when we have it 🙂

joshkh 2020-09-25T19:37:50.009800Z

much appreciated, Jaret

seancorfield 2020-09-25T19:51:07.010400Z

I didn't see anything stating the new version of REBL in dev-tools -- I had to download the ZIP to find out what the latest version was (0.9.242) so that I could put it in my deps.edn and pull it from the Cognitect Maven repo.

seancorfield 2020-09-25T19:51:54.010600Z

(and, yes, I know that having downloaded the ZIP, I don't need to set it up that way -- I could just use a local install -- but I prefer the idea of being able to get things direct from Maven)

jaret 2020-09-25T19:54:16.010800Z

Thank Sean, I'll share this with the team and see what we can do.

Michael J Dorian 2020-09-25T19:56:36.011700Z

Hey! I want to pull all data on an entity based on it's entity id, can anyone tell me what's wrong with this query? (d/pull (d/db conn) [:db/id 79164837199970])

Michael J Dorian 2020-09-25T19:57:31.011800Z

I know the id based on a previous query


missing colon on :db/id

Michael J Dorian 2020-09-25T20:02:18.012200Z

Ah, had that messed up. This isn't working for me either, it just says

Execution error (NullPointerException) at com.google.common.base.Preconditions/checkNotNull (Preconditions.java:782).
(d/pull (d/db conn) [:db/id 79164837199970])

souenzzo 2020-09-25T20:02:46.012400Z

[:db/id 42] isn't a valid lookup eid it should be just 42

Michael J Dorian 2020-09-25T20:03:18.012700Z

like so? (d/pull (d/db conn) 79164837199970)


Ah, right, that’s true

souenzzo 2020-09-25T20:03:24.013100Z


Michael J Dorian 2020-09-25T20:03:58.013300Z

I guess there's something wrong with the query I'm getting this id from then, I'm still getting null pointer exceptions


funny, though, why wouldn’t that work just like any other unique ID pair?

souenzzo 2020-09-25T20:04:21.013700Z

:db/id isn't a "datomic ident" There is no [42 :db/id 42] tuple in "datoms stack"


@doby162 Are you sure you haven’t lost the conn? That could give you an NPE


@souenzzo Ok, that makes sense


I guess I’ll aways be an old SQL guy at heart

Michael J Dorian 2020-09-25T20:06:35.014500Z

I don't think so, I can still run a query that gives me [[79164837199970]] and all of my functions are making a fresh (d/db conn)

Michael J Dorian 2020-09-25T20:07:51.014700Z

the query that gives me the id is

[:find ?e                                                                                                             :where                                                                                                                 [?e :user/email ?email]] 

Michael J Dorian 2020-09-25T20:08:23.014900Z

which, if I'm not mistaken, should just give me the entity ids of anything with an email address

csm 2020-09-25T20:19:38.015100Z

you don’t have a selector, you’d need (d/pull (d/db conn) '[*] id) to pull everything for id.

csm 2020-09-25T20:20:33.015300Z

Client api can also use an arg map: (d/pull db {:selector '[*] :eid id})

Michael J Dorian 2020-09-25T20:21:25.015500Z

thank you, that did it!


Yeah that was it, I was looking up the docs:

([db pattern eid])
  Returns a hierarchical selection of attributes for eid.

         See <http://docs.datomic.com/pull.html> for more information.


I was just working with pull expressions too, should have spotted that sooner.

Michael J Dorian 2020-09-25T20:22:46.016100Z

Sorry for the silly question, these docs have a lot of "..." that really throws me off. I'm curious why I didn't get an arity exception though


Yeah, seems like you should have.

Michael J Dorian 2020-09-25T20:23:26.016500Z

Oh, I guess I could have included the selector and :eid all in a map. All makes sense now. Thanks everyone!