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
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
Well, if you ever find an answer please let me know
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.
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 pendo1
and would still tie these times precisely to transactions and their txinstant
That's clever @favila
Those attributes could be applied generally too, no need to make
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:
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
What if one of those transaction were modifying an attribute that you're not returning from the query?
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
what does it mean to “create” an entity? it’s just a number
“txInstant of first assertion on this entity id?”
thanks. I thought that was the case. shame but core.match will work too
but you see how that’s not an obviously universal meaning of “created_at”? A specific domain may have a different one