Fork me on GitHub
#datomic
<
2018-01-04
>
hansw07:01:53

just checking... Datomic only allows the use of java.util.Date, correct?

hansw12:01:07

that requires me to login?

souenzzo12:01:20

I think that you need to access from http://my.datomic.com (top, right button) from the first time But it's a suggestion to support java.time.instant. And the feedback from datomic team:

We're gathering feedback from customers, so that we can gauge demand for this feature. Make sure to click "Want" on this feature if you need it.
Marshall Thompson
from Datomic wrote a year ago

hansw13:01:35

will upvote

hansw07:01:09

I'm surprised they haven't jumped on the goodies in java.time as of JDK8, being immutable and all...

hansw07:01:35

Probably for backwards compatibility?

michaels14:01:53

java.util.Date is the source of 95% of my problems. (The other 5% being NPEs.)

hansw14:01:04

i'm surprised they opted to use java.util.date to begin with... joda-time has been the better option for ages

michaels14:01:18

That seems to be the case for a lot of libraries. Jackson doesn’t do serialization natively of them, and we’ve had problems with other libraries as well. 😕

hansw14:01:05

interesting choices 🙂

hansw14:01:38

reasons could be something legal...

hansw14:01:13

maybe something to do with licensing or whatever

hansw17:01:59

What would it look like when I 'update' an entity to have the value for an attribute removed? Set it to nil?

hansw18:01:59

aha, :db/retract

favila19:01:13

Is there an efficient way to look up a transaction in the log by its uuid?

favila19:01:00

This is an approximation which I'm not sure would even work with transactions which set a txInstant explicitly:

favila19:01:08

(defn lookup-tx-by-uuid [log tx-uuid]
  (let [start (Date. (d/squuid-time-millis tx-uuid))]
    (->> (d/tx-range log start nil)
         (drop-while #(not= (:id %) tx-uuid))
         first)))

favila19:01:14

I was hoping there was something better

cjsauer19:01:57

Hey all, when Datomic Starter says that "updates are limited to one year", does that mean that after 1 year my CI servers will break (they won't be allowed to pull the JAR file)? I'm trying to figure out how exactly the licenses work. If I'm ok with not receiving updates after 1 year, would I need to host that JAR file somewhere manually?

cjsauer19:01:14

Or do I sort of automatically get "locked in" to whichever version is available when my updates expire?

Alex Miller (Clojure team)19:01:24

@marshall is a good guy to answer such questions

marshall19:01:58

@cjsauer your license key wont work to start transactor versions released past the maintenance period it will no affect your ability to fetch the peer lib for CI

marshall19:01:20

in general it is best to keep parity between peers/transactor in terms of version

cjsauer19:01:25

@marshall thanks for the response. Makes perfect sense.

marshall19:01:02

@favila I can’t think of anything better off the top of my head

marshall19:01:57

it should be pretty fast since you’re starting the tx-range call at the millisec of the txn of interest

favila19:01:12

is there a guarantee that the tx-uuid's squuid ms part will be = or < the txInstant?

marshall19:01:25

that i’m not sure about

favila19:01:48

I would assume this would be false for backdated txs (with explict txInstant)

favila19:01:11

this fn wouldn't work in those cases; only a full scan of the log would find the uuid

favila19:01:52

ok. I am a little sad but this is ok; it's something we use for forensics anyway

favila20:01:05

(digging around in a repl)

marshall20:01:43

yeah, the only other option i can think of would be to walk the log and export uuids with tx-ids to something like elasticsearch

marshall20:01:59

which you could do batchwise

favila20:01:36

I was a little surprised to discover also that tx-range's start parameter is interpreted like d/as-of when a date

favila20:01:45

it doesn't mean "give me txs with this txInstant or later", it means "give me the TX that is the final one at this txInstant or later"

favila20:01:34

so if you ask for time x and there's no tx at time x, the first tx you get from the seq will be from time < x not > x

favila20:01:38

is that intentional?

marshall20:01:57

the docs say “The arguments are startT (inclusive), and endT (exclusive). Legal values for these arguments are:”

marshall20:01:48

so you’re saying you get a tx with txInstant before the date you passed?

favila20:01:12

I expected txInstant to always be >= start-instant

marshall20:01:14

that seems inconsistent with my expectation

marshall20:01:39

any chance you have a small repro?

favila20:01:36

I discovered it working with a prod db but it should be easy to reproduce with a test db

marshall20:01:56

ok. i’ll look into it also, but if you get one please do file a ticket

favila20:01:02

This is how I found it:

(-> (d/log pc) (d/tx-range #inst"2018-01-04T18:41:54.000-00:00" nil)
    (->> (take 2)
         (map tx->times))
    )
=>
([[53635182 #uuid"5a4e7571-f3c6-4f58-bcd6-f0da00a898de"]
  [1515091313000 #inst"2018-01-04T18:41:53.000-00:00"]
  [1515091313924 #inst"2018-01-04T18:41:53.924-00:00"]]
 [[53635183 #uuid"5a4e7572-fcd8-47ee-a89d-ded605b565df"]
  [1515091314000 #inst"2018-01-04T18:41:54.000-00:00"]
  [1515091314031 #inst"2018-01-04T18:41:54.031-00:00"]])

favila20:01:37

(the first time in each entry is the squuid-time-ms from the tx-uuid; the second one is the tx's txInstant)

marshall20:01:05

interesting

marshall20:01:15

it’s like there’s a rounding issue

marshall20:01:27

i know d/squuid rounds to seconds

favila20:01:46

yeah, that's fine. I don't think txid is used by tx-range

favila20:01:53

the important bit is the second time

marshall20:01:02

hrm. actually i wonder if it’s in the t->tx vs tx->t conversion

marshall20:01:34

err the datetime to tx/t i mean

favila20:01:47

I don't think so

favila20:01:50

here is the boundary:

favila20:01:52

(-> (d/log pc) (d/tx-range #inst"2018-01-04T18:41:54.030-00:00" nil)
    (->> (take 2) (map tx->times)))
=>
([[53635182 #uuid"5a4e7571-f3c6-4f58-bcd6-f0da00a898de"]
  [1515091313000 #inst"2018-01-04T18:41:53.000-00:00"]
  [1515091313924 #inst"2018-01-04T18:41:53.924-00:00"]]
 [[53635183 #uuid"5a4e7572-fcd8-47ee-a89d-ded605b565df"]
  [1515091314000 #inst"2018-01-04T18:41:54.000-00:00"]
  [1515091314031 #inst"2018-01-04T18:41:54.031-00:00"]])
(-> (d/log pc) (d/tx-range #inst"2018-01-04T18:41:54.031-00:00" nil)
    (->> (take 2) (map tx->times)))
=>
([[53635183 #uuid"5a4e7572-fcd8-47ee-a89d-ded605b565df"]
  [1515091314000 #inst"2018-01-04T18:41:54.000-00:00"]
  [1515091314031 #inst"2018-01-04T18:41:54.031-00:00"]]
 [[53635184 #uuid"5a4e7572-61de-4103-b5fd-cb2ed253ed4e"]
  [1515091314000 #inst"2018-01-04T18:41:54.000-00:00"]
  [1515091314254 #inst"2018-01-04T18:41:54.254-00:00"]])

marshall20:01:30

what’s your backend storage?

favila20:01:37

this db is sql

marshall20:01:02

wasn’t ever backed up / restored from ddb or any other storage?

favila20:01:36

maybe from dev, ages ago? never ddb

marshall20:01:48

dev wouldn’t do what i was thinking

cjsauer20:01:41

@marshall just hypothetically, if a security hole were discovered in Datomic, would Datomic Starter users outside of their license receive any retro-patches? I'm imagining no, but wanted to double check.

marshall20:01:23

@cjsauer well, it hasn’t happened and i hope it doesnt, but I suspect that decision would probably be made at that time I would not be the one making it 🙂

cjsauer20:01:09

@marshall gotcha. Appreciate the help.