@zentrope if you throw an exception from a tx function then nothing is added to the durable store, similar to rollback

@stuarthalloway Thanks. I personally like that approach.

@jdkealy: tests on circleci are totally possible IF your tests use a memory database - datomic:mem://

@robert-stuttaford: CI aside, that’s a pattern I’d suggest anyway

yep!

Storing information in reified transactions can be pretty inflexible sometimes

I wrote an exporter that exports a (subset of) a prod db, so that developers can use it as a dev db on their laptops

The exporter exports the datoms but transacts them in a different granularity (in chunks of 1000)

But this also means that the dev dump lacks the tx metadata

We're using conformity for migrations, which uses tx metadata to mark transactions as "already performed".

Unfortunately, this means that conformity considers all txs as "not yet performed", which leads to issue with schema alterations.

And as transactions are immutable, it's not easy to fix after the fact.

yep. you basically have to not-use-conformity for schema in your dump db

I mean it works for the most part, until you start renaming attributes

(I don't know why we started doing that, not a good idea unless you're forced to)

is there an idiomatic way to get enums in query results as keywords (their :db/ident)?

if i do pull [* {:user/status [:db/ident]}] i get a nested map which is an unnecessary complication

@onetom, pull does that by design, because you may have other things on that entity that you care to pull

d/entity returns the keyword; d/pull returns what you've printed

awesome, thanks!

@pesterhazy I think the inflexibility is in the exporter, not in reified transactions. The exporter ignores a semantic of the db, so you cannot then expect that semantic to be preserved

and conformity is hardly the only thing that uses reified transactions

@robert-stuttaford: I was listening to your podcast episode on Datomic on a plane ride; it was interesting to hear about your experiences even though I’m already somewhat familiar with datalog/datomic/datascript -- thank you 🙂

absolutely my pleasure 🙂

was great fun to chat to the guys. it got Deep Nerd in there

Is there anything I can do to reduce transactor memory usage? I'm using datomic for a personal project; the database is only a couple hundred MB, but the transactor is eating 1.5G of memory.

Is there any way to log dynamodb requests?

Specifically a slow log? (e.g. log request id every time a request takes longer than Xms)

@robert-stuttaford but how do you boot the transactor? do you need to create a docker container ?

@codonnell: The transactor by default launches with 1 gig of memory. You can modify the properties in the transactor properties file and try to push this lower, but 1 gig is recommended for use on laptops/development. The transactor also accepts java arguments when executed so you can pass in -Xmx1g or whatever your desired memory usage is.

@jdkealy we use the AWS AMI that Datomic provides, after sprinkling some http://datadoghq.com agent code on it

howdy @jaret 🙂

Hey @robert-stuttaford !

Is this a reasonable way to get the last few transactions or will it perform poorly for large transaction logs? (take-last 5 (d/tx-range (d/log connection) nil nil))

potetm I’m not sure I’ve ever seen a slow request in dynamo. i.e. I don’t think it’s possible to write a slow query, aside from scan