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.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.
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
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.