datomic

Ask questions on the official Q&A site at https://ask.datomic.com!
tatut 2021-01-13T05:05:14.248700Z

I did the same, but then you can’t use :rev but have to have :uname instead

tatut 2021-01-13T05:05:19.248900Z

as the git tree isn’t clean

Ben Sless 2021-01-13T13:49:48.251100Z

Looks like you can get really close by using graphviz records

stuarthalloway 2021-01-13T15:03:22.252300Z

@jshaffer2112 et al, happy to get opinions on moving Cloud to JVM 11, been wanting to do that for a while. Anybody see downsides?

6➕
steveb8n 2021-01-14T21:23:47.007100Z

I'm with John on this. If it was a reversible flag in case some lib doesn't work, that would add a lot of confidence when trying this migration

1
hadils 2021-01-15T16:11:49.016300Z

Just chiming in here -- I am in favor of moving Cloud for JVM 11. We are still in early stages of our product and the conversion won't be that painful.

JAtkins 2021-01-13T15:46:21.252700Z

Wouldn't it be? Ions can only push from clean git trees*, and if you ignore the build repos nothing should change anyway. I used git rev-parse HEAD

kenny 2021-01-13T15:55:28.255800Z

The only change we had to make when moving from 8 -> 11 was adding --add-opens=java.base/jdk.internal.ref=ALL-UNNAMED to our jvm opts for Neanderthal. Everything else has been exactly the same. It’s been nice to have access to the built in http client and some of the newer date methods, like the one John referred to, without needing to wrap them.

john-shaffer 2021-01-13T20:04:44.256400Z

Can it start as a stack parameter for the JVM version? That would give people plenty of time to work out issues like kenny's