datahike

2025-12-15T05:49:50.990609Z

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.

whilo 2025-12-18T20:29:30.378759Z

I have merged https://github.com/replikativ/datahike/pull/740, try with the latest release https://github.com/replikativ/datahike/releases/tag/0.6.1611. I think this might fix your problem.

whilo 2025-12-18T20:30:07.602029Z

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

whilo 2025-12-18T20:31:08.354059Z

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.

whilo 2025-12-18T21:13:35.555909Z

I think this PR does not quite solve your problem.

whilo 2025-12-18T21:46:41.029879Z

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.

2025-12-29T10:14:41.203859Z

ok. i will, but a bit later

2025-12-15T05:57:46.397359Z

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])

2025-12-15T06:00:51.528859Z

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

whilo 2025-12-28T23:14:49.389869Z

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

whilo 2025-12-28T23:15:33.299519Z

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

2025-12-21T20:28:16.409419Z

I will try. Sure. and report here

2025-12-21T20:29:51.686959Z

> 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

2025-12-21T20:31:28.023869Z

> 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

whilo 2025-12-21T20:32:34.655519Z

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
whilo 2025-12-21T20:42:56.693039Z

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

2025-12-21T22:06:25.080269Z

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

2025-12-15T16:55:13.725449Z

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