datahike 2025-12-15

Hello all! I don't know if it is a bug or my conceptual misunderstanding, but looks like first... I encountered something weird on merging database branches 🤔 Attribute schema:

{:db/ident :driver/live-location
  :db/valueType :db.type/tuple
  :db/tupleTypes  [:db.type/instant :db.type/float :db.type/float]
  :db/cardinality :db.cardinality/one
  :db/doc "Last driver's live location (time, lat., lon.)"}
In tests I am writing it to branched database and then merge in "main". Twice it's okay. When attribute is "new" for two different entities. But on third time, when I am changing the live-location of one driver, transaction to branched database is successful, but on (dv/merge! connection #{branch} tx-data) Datahike raise this:
2025-12-15T05:39:56.249Z mbpm2-avbo.local ERROR [datahike.db.search:51] - Bad format for value in pattern, must be a scalar, nil or a vector of two elements. {:error :search/pattern, :v [#inst "2025-12-15T05:39:53.898-00:00" 15.6683 73.7185], :pattern [96 :driver/live-location [#inst "2025-12-15T05:39:53.898-00:00" 15.6683 73.7185]]} 
I put more info in thread.

Pretty cool that you are using the merging, I need to polish this a bit and make it part of the main API.

Btw. I also worked on the dynamodb support, it should be able to now write in one dynamo transaction and hopefully have optimal latency in this way. I have not had the time to test this seriously yet though.

I think this PR does not quite solve your problem.

I am not sure, I think you hit upserts because of cardinality/one, so this might be the problem which is solved in the PR and will only show up after you added the tuple initially.

ok. i will, but a bit later

tx-data on merges related to live-location This two were successful:

([:db/retract 96 :driver/uuid #uuid "1530d376-2df8-4318-a51d-8db173c03876" 536870927]
 [:db/add 96 :driver/live-location [#inst "2025-12-15T05:39:53.898-00:00" 15.6683 73.7185] 536870929]
 [:db/add 96 :driver/uuid #uuid "1530d376-2df8-4318-a51d-8db173c03876" 536870929])
([:db/retract 243 :driver/uuid #uuid "966b09f9-4b56-4bcc-b9cb-6ef6f3bd35d3" 536870986]
 [:db/add 243 :driver/live-location [#inst "2025-12-15T05:39:55.905-00:00" 15.689 73.7137] 536870988]
 [:db/add 243 :driver/uuid #uuid "966b09f9-4b56-4bcc-b9cb-6ef6f3bd35d3" 536870988])
But when I trying to update a value, it fails(((
([:db/retract 96 :driver/live-location [#inst "2025-12-15T05:39:53.898-00:00" 15.6683 73.7185] 536870929]
 [:db/retract 96 :driver/uuid #uuid "1530d376-2df8-4318-a51d-8db173c03876" 536870948]
 [:db/add 96 :driver/live-location [#inst "2025-12-15T05:39:56.235-00:00" 15.6843 73.7111] 536871004]
 [:db/add 96 :driver/uuid #uuid "1530d376-2df8-4318-a51d-8db173c03876" 536871004])

Important to say that many another attributes successfully updates and merges. Datahike version 0.6.1610

i decided to release clj-rocksdb myself to get it out: https://github.com/replikativ/datahike-rocksdb

if you can give me a more comprehensive test case to reproduce and what the intended behaviour should be then i can take a look

I will try. Sure. and report here

> Pretty cool that you are using the merging, I need to polish this a bit and make it part of the main API. Merging is crucial part for me to support kind of pure functional requests handling

> Btw. I also worked on the dynamodb support, it should be able to now write in one dynamo transaction and hopefully have optimal latency in this way. I have not had the time to test this seriously yet though. that's cool but I leaved AWS infra on my projects. Too unpredictable compute prices and etc... now using common JDBC connector to Postgres/CockroachDB

ok, cool; i also have updated the rocksdb backend which should also provide lower latency than the alternatives (i guess), if this is important for your application

👀 1

to merge it i am still waiting for a PR being merged into clj-rocksdb upstream https://github.com/t44k/clj-rocksdb/pull/6

No((( it still failing on transacting database schema except first time. Schema is re-transacted on every start of database module. There are some heterogenous tuples in it. At start with empty backend database it works well, but if I restart application, then it fails with "class java.lang.Long cannot be cast to class clojure.lang.IFn (java.lang.Long is in module java.base of loader 'bootstrap'; clojure.lang.IFn is in unnamed module of loader 'app')" on schema transaction. Backend - JDBC Postgres in docker. Version of Datahike the last one 0.6.1611

FYI When I refactored tuple to three separated attributes - everything works.