I'm seeing some weird behaviour. I expect these three queries to give the same output:
(count (dh/q {:query '[:find ?uid :in $ :where [?e :business/id ?uid][(missing? $ ?e :business/referrer)]] :args [(dh/as-of @conn (t/inst (t/midnight (t/date "2024-12-31"))))]})) =>> 644(count (dh/q {:query '[:find ?uid :in $ :where [?e :business/id ?uid][(missing? $ ?e :business/referrer)]] :args [(dh/as-of @conn (t/inst (t/midnight (t/date "2024-12-12"))))]})) => 644(count (dh/q {:query '[:find ?uid :in $ :where [?e :business/id ?uid][(missing? $ ?e :business/referrer)]] :args [@conn]})) => 965Without as-of all the business ids a returned, but with as-of some are ignored
That looks like a bug. Do you have any sense where the 644 might come from? It might be good to compare directly part of the index or query results instead of just the counts, in particular the tx timestamps that are in the result set.
The tests don't seem to cover future as-of references, does as-of for the past work for you?
@whilo I looked at the data. I think I did migration in march and last the tx timestamps.
So in as-of they're ignored.
Would there be a way to give all the datoms without timestamps new timestamps no a particular date
What do you mean with "and last the tx timestamps"?
Datom 144 has no timestamp so it's left out of as-of . Can I query all datoms without a timestamp? And then assign a new timestamp so that Datom 144 has a new timestamp.
@whilo does that make sense?
I would just scan over d/datoms , that should be most transparent and hopefully fast enough.
Or modify the export/import.
@pat has helped to make Datahike compile in cljs again https://github.com/replikativ/datahike/pull/724, anybody interested to hack on this and get it working (we need to work through all the tests basically)? Our goal for now is to get cljs in-memory working again and then wire it up to the server such that you transact against a server backend, but keep everything in the frontend in-memory similar to DataScript. This will allow you to run Datahike queries synchronously in cljs. After that we can port the code over to allow asynchronous execution that can also fetch index fragments from remote servers on-demand and potentially respect backpressure from the consumer to only do the work needed (similar to returning a lazy seq for a Datomic query).
This is super awesome. That would open up aws-lambdas or firebase cloud functions
It might also blend nicely into Electric, basically sharing user specific databases between frontend and backend right away while using its programming model to join all the data in both environments.
For lambdas we can already use the native image, but our binary is still too large for snappy cold starts it seems. Cljs might indeed be faster there.
I could test this.
Like once it is working. I have a lot of backlog for now on frontend work.