Fork me on GitHub
#datomic
<
2018-01-26
>
luchini15:01:42

We are investigating using tx-report-queue from the the Peer Client library. Datomic Cloud and the new Client API doesn’t seem to support it. Is there an alternative or are we stuck to On-Prem?

marshall15:01:49

@luchini You can use the log API to poll for updates

luchini15:01:28

@marshall the app we are building has a series of client nodes that need to react when certain transactions have finished. Our initial thought was a light-weight passive approach if possible. With polling we’ll need to have a cron-like feature polling from each client. Won’t this be too heavy?

marshall16:01:17

@luchini how much polling and how often would it have to do so?

marshall16:01:16

also, you can get the latest db value from a conn and only query the log when the basis-t has changed

luchini16:01:20

The intention is to give a real-time feeling to users… so, potentially frequent 🙂

cjsauer17:01:24

Currently preparing to switch our db from on-prem to cloud. Is there a guide available for doing this efficiently? It'd be awesome if I could just reuse my current dynamo table, but I'm thinking an import/export operation will be necessary...

donmullen17:01:48

@cjsauer It’s my understanding that the migration story and tooling are a WIP.

cjsauer18:01:58

Ah ok. I'm imagining breaking it down like this: 1. Launch datomic cloud in AWS 2. Migrate from peer to client API 3. Export all data from old db (all this while site is in maintenance mode) 4. Import all data into new db My main concern is with step 2...it looks like my local dev workflow will change rather drastically. Currently I'm just using a datomic:mem://... setup to develop locally. Is something like this possible using the client API?

luchini17:01:41

@stuarthalloway approx 1k users for MVP and up to 20k in the long run. We are thinking of 2 client nodes for starters and scaling up to max 10.

stuarthalloway18:01:48

@luchini I don’t think that 2-10 clients polling the log would be a problem. What poll interval would meet expectations?

cjsauer18:01:58

Ah ok. I'm imagining breaking it down like this: 1. Launch datomic cloud in AWS 2. Migrate from peer to client API 3. Export all data from old db (all this while site is in maintenance mode) 4. Import all data into new db My main concern is with step 2...it looks like my local dev workflow will change rather drastically. Currently I'm just using a datomic:mem://... setup to develop locally. Is something like this possible using the client API?

stuarthalloway18:01:34

@cjsauer what I have been doing is run against a bastion + Solo topology for interactive development from the REPL. Need a network connection, but with that in place it is very cool

stuarthalloway18:01:21

having a real db beats memory db — you can come back to it tomorrow

cjsauer18:01:05

That makes sense. I suppose I can also include the datomic-socks-proxy script right in my repo for the rest of the team.

stuarthalloway18:01:39

yes, one thing that is cool is that connection security lives entirely outside the config, so the proxy script and connection config are safe things to have in a repo

denik18:01:45

@dnolen mentioned a js client for datomic in his talks. What is the roadmap and estimate release date?

dnolen18:01:36

@denik far as I know there is no roadmap, and no estimated release date

dnolen18:01:26

but clients are pretty simple, you can examine the Clojure client source - wire protocol just needs more documentation

denik18:01:26

@dnolen where can I find the source?

dnolen18:01:47

in the Clojure client JAR

stuarthalloway18:01:37

@luchini that polling load seems fine, let me know if you encounter issues

timgilbert18:01:37

Say, in the datomic entity API is there a way to enumerate the backrefs of an entity?

timgilbert18:01:53

(Apart from just (:back/_ref entity) - I can get the forward refs via (keys entity))

drewverlee19:01:22

I found this article on business logic in the DB very interesting. http://www.vertabelo.com/blog/notes-from-the-lab/business-logic-in-the-database-yes-or-no-it-depends Has anyone written about the idea of business logic being in the db (constraints, stored procedures, validation, data integrity, etc…) from a datomic perspective?

stuarthalloway19:01:23

@drewverlee the reddit critics that the author quotes are more about the historical legacy of specific SQL database implementations than about databases in general

stuarthalloway19:01:48

e.g. “How the hell do you unit test your business logic when it’s in the database?”

stuarthalloway19:01:11

I would counter with “How do you test anything that isn’t written in a functional style?”

stuarthalloway19:01:25

… not that you cannot test imperative code, but it is a lot harder

cjsauer19:01:34

Running into this while trying to migrate from peer to client API: java.lang.RuntimeException: No reader function for tag db/id, I'm probably missing something obvious...

drewverlee19:01:00

@stuarthalloway thanks for the reply. I agree, its harder to test imperative anything. I’m doing a lot of backend api work currently, which means turning HTTP requests into sql queries. I have talked a bit with experts that made we aware of a lot of issues that can happen when you keep a lot of logic in the db. They suggest that db constraints (at least in most relational dbs) can’t fully model the range of business logic constraints you want. That chained triggers are hard to follow because there reactionary. The changing a database with lots of constraints is hard. All these arguments against business logic in the db make sense, as do the ones in that article. My institution tells me that i want * the semantics of my system to be uniform across by db and clients/servers * validations and security at the persistent layer (so in the db) Sense Datomic offers at least the first one and possible the second, it might change the conversation around the pros and cons of pushing more and more logic into db like queries. I feel drastically uneducated about this entire topic.

cjsauer20:01:59

Added datomic-free as a dependency for the data-readers support to fix the above. Migrating from peer to client API is turning out to be really tricky actually...these deps run pretty deep in my source code. May have to rethink my plan :thinking_face:

jocrau21:01:53

@cjsauer The Client API does not support #db/id tempids. I replaced the ids with strings and it worked. More here: https://docs.datomic.com/on-prem/moving-to-cloud.html

cjsauer22:01:17

@jocrau thank you! That link was exactly what I was after.