Ask questions on the official Q&A site at https://ask.datomic.com!
em 2021-03-03T00:09:09.064800Z

Looks fantastic, thanks for all the hard work! Just to clarify, by Lambda runtimes moving to NodeJS, does that mean that lambda the ultimate proxies are now entirely on node? I.e., no more JVM 2s cold starts

xceno 2021-03-03T10:14:43.069300Z

Since datomic cloud/ions run on java 1.8, would I need to spin up a separate EC2 instance in my datomic VPC when I need to use a newer version, or can we somehow upgrade/change the JDK for a specific ion? Also, generally speaking when I need certain system dependencies in an Ion, like e.g. Python 3.8 or whatever, is there any way to get this stuff set up inside an ion? I couldn't find any answers to those questions in the forum or anywhere else

xceno 2021-03-05T18:32:30.110800Z

Well, if you ever find an answer please let me know

em 2021-03-05T23:12:01.111Z

Been digging through the docs all day but couldn't find anything more specific pertinent to this. I'm thinking maybe this is something you'd need to do outside Datomic, on configuring the EC2 instances directly? (for python etc., I don't think we can change JDK for ion applications). Not sure if that'd work. That said, if you're doing heavy compute through python libs etc. I'd imagine you wouldn't really want to run those nodes inside Ions anyway, as the overhead of maintaining query group cache, being part of the High Availability fall back group, etc. is probably not desirable. It would make sense just to spin up your custom compute heavy nodes inside the VPC and access Datomic as a client.


Datomic Analytics is really cool! Is it possible to expose created-at/updated-at like attributes on the tables?


A possibility for us would be to expose multiple presto endpoints on different d/as-of . That'd also ensure a consistent view of the data.

favila 2021-03-04T14:31:39.084200Z

Have you considered adding a “creating-tx” and “last-modifying-tx” attribute to your entities that references a transaction? That would be both faster (no history index needed to determine it) and exposable via pendo

favila 2021-03-04T14:32:27.084400Z

and would still tie these times precisely to transactions and their txinstant

Joe Lane 2021-03-04T14:32:33.084600Z

That's clever @favila

Joe Lane 2021-03-04T14:34:02.084800Z

Those attributes could be applied generally too, no need to make :user/creating-tx .


Thatd allow for indexing too. Sounds promising. I'll suggest it to the team. Just need to make sure to include that attribute in related transactions (but that could be generic too I recon)... Thanks!


In our systems we use the transaction log to show them in the frontend. which is 👌:skin-tone-2:👌:skin-tone-2:

Joe Lane 2021-03-03T19:40:26.072900Z

What would either of those the times represent?


Some information about transactions on the entity. I.e. the most and least recent transaction instant would be most interesting for us

Joe Lane 2021-03-03T20:41:21.075Z

What if one of those transaction were modifying an attribute that you're not returning from the query?

Joe Lane 2021-03-03T20:41:45.075200Z

Does "lastmodified" even make sense at an entity level?


Valid point. In our usecase we mainly need created at. We want to use it to see influx of users over time for example

favila 2021-03-03T21:29:28.077300Z

what does it mean to “create” an entity? it’s just a number

favila 2021-03-03T21:30:14.077500Z

“txInstant of first assertion on this entity id?”


Yes exactly.

steveb8n 2021-03-03T22:35:01.078900Z

thanks. I thought that was the case. shame but core.match will work too

favila 2021-03-03T22:48:34.079100Z

but you see how that’s not an obviously universal meaning of “created_at”? A specific domain may have a different one