Not currently. You can lookup data from a custom source within your query using a custom predicate though

that's correct, yes - apart from being schema-less, our bitemporality also means that you can insert data at any point in the past/future, which wouldn't play so well with noHistory

Some of those use cases would be covered by the eviction in crux instead.

thanks!

^ eviction - that's an interesting point, it could be a good option to create something similar. It doesn't incur expensive index rewrites like excision does (in case that's a concern)

> there is only one version for any point in time not sure I quite get what you're looking for here 😕 let's say we were to consider bitemporality as a 2D graph, valid-time on one access, transaction-time on the other - the update pattern you're talking about would currently look like a lot of dots along the vt=tt 45° diagonal - what might you want it to look like?

based on that, I think "noCorrectionHistory" is probably a more accurate description as far as Crux is concerned 🙂

got it. Do you require atomicity with the regular Crux transactions?

yes!

It's possible you could do something clever with (e.g.) Kafka transactions to keep the main tx-log free from atemporal churn, whilst retaining atomicity. Is this a deal breaker? It might be a good point to chat

yes, happy to chat

monday or tuesday? I’m on EST time, mostly available 12-6pm

will DM

i'd be curious to know as well--i've begun https://github.com/lgessler/glam/blob/master/src/main/glam/crux/easy.clj in my own project by expanding transaction ops with update and merge via transaction and writing a few other convenience functions. but this is not a mature solution at all

did you already see https://findka.com/biff/#introduction ?