Fork me on GitHub
#datomic
<
2015-07-29
>
robert-stuttaford08:07:54

should i be seeing a different d/basis-t value for an d/as-of database in the past?

robert-stuttaford08:07:20

no matter what i do, i’m always getting the same basis-t and next-t values back

robert-stuttaford09:07:00

anyone have any ideas?

tcrayford09:07:00

@robert-stuttaford: I think it's because basis-t is an implementation detail that's leaking through as-of? Recall the part of @stuarthalloway's recent ete datalog talk about the history filters. as I understand things, as-of etc are implemented as things that a) filter the index b) merge the live index and parts of the history index. I don't think any of those actually needs to affect basis-t

tcrayford09:07:10

@robert-stuttaford: uh, bad terminology there. When I say "live index" in that para, I mean as opposed to the historical indexes, not the peer in memory stuff

caskolkm14:07:18

@(d/transact conn [[:db.fn/retractEntity (BigInteger. company-id)]] causes a:

caskolkm14:07:21

db.error/reset-tx-instant You can set :db/txInstant only on the current transaction

caskolkm14:07:35

Does anyone know what I'm doing wrong?

bostonaholic14:07:12

@caskolkm: I was getting the same error earlier this week. Unfortunately, I don't believe I solved it. (Just deleted and recreated my local db)

bostonaholic14:07:39

I know that probably doesn't help much 😜

bostonaholic14:07:01

plus I usually do (Long. eid)

bkamphaus14:07:33

@robert-stuttaford: kind of late, but if you want the as-of point you need to use as-of-thttp://docs.datomic.com/clojure/#datomic.api/as-of-t, likewise since requires since-t http://docs.datomic.com/clojure/#datomic.api/since-t

robert-stuttaford15:07:43

@bkamphaus: thanks. i do recommend you update the docstrings for basis-t and next-t, because they are not correct

robert-stuttaford15:07:26

"Returns the t of the most recent transaction reachable via this db value.”

robert-stuttaford15:07:07

perhaps just a note that its result is not constrained by d/as-of or d/since

caskolkm15:07:57

@bostonaholic: weird.. Hopefully someone else knows the answer :)

bostonaholic15:07:34

I just tried it again and it worked...

bkamphaus15:07:41

@robert-stuttaford: I think you’re correct that there may be doc improvements that would make sense around using filters, but I don’t think that is necessarily one of them. Sorry, I’m still working on how to best phrase it, but the db value returned by a call to a filter (`as-of`, since, or your own) - is a db value with the filter applied. the as-of-t and basis-t are different, but basis-t is still the correct basis of the filtered db, even though the filter may filter our the most recent (or several of the most recent) tx(es).

bkamphaus15:07:01

another angle of this, that the db-after returned by with for an as-of db filter filters out the prospective data, is also surprising.

bkamphaus15:07:54

@bostonaholic: and cc @caskolkm if you’re able to repro I’d be curious to see, but you’re correct that entity id’s should be java.lang.Long and I’d want to see it repro’d using the correct type of arg to retractEntity

robert-stuttaford16:07:51

@bkamphaus: thank you for your feedback

robert-stuttaford16:07:34

not sure what the right way forward is, i just know that it’s not obvious that this is the case, and it can catch people. certainly caught me, and i’ve been using Datomic for a long time

caskolkm16:07:39

@bostonaholic: can you show me your code?

bostonaholic16:07:32

it was the same as yours, just (Long. eid) is different

caskolkm16:07:56

Ok, i will try it tomorrow

tcrayford16:07:30

@robert-stuttaford: as somebody who's also been using datomic for a long time, I agree that it's confusing 😞