2026-02-19 datalevin | Clojure Slack Archive

datalevin

Samuel Ludwig 2026-02-19T17:51:31.680699Z

Is it expected that the value 42 of type java.lang.Integer will not match the value 42 of type java.lang.Long? Example:

(d/transact! conn [{:db/id -1, :my-entity/val (int 42)}])

(d/q 
  '[:find ?e :in $ 
    :where [?e :my-entity/val 42]] 
  (d/db conn))
;;=> ()

(d/q 
  '[:find ?e :in $ 
    :where [?e :my-entity/val (int 42)]] 
  (d/db conn))
;;=> (some-output)

Huahai 2026-02-19T17:53:00.113969Z

Yes, it's expected. The binary encoding is different.

Samuel Ludwig 2026-02-19T17:54:40.965889Z

I see I see, appreciated

magra 2026-02-19T20:41:24.031409Z

With dlmdb being a fork of lmdb: pkg install lmdb installs among other things /usr/local/bin/mdb_dump, mdb_copy, mdb_load and mdb_stat. When I build a port for FreeBSD the two will not be able to be installed at the same time, a conflict will be reported when one tries to install one of them and the other one is already installed. One aspect of this ist, that one could aspire to "backward compatibility" and always rebase to any new development of lmdb. The big BUT second aspect is, that ports or packages depending on one of them can not coexist with ports or packages depending on the other one. Other packages that depend on lmdb are mutt and samba. This will not be a big problem on servers that normally run pretty thin jails and I would never dream of having samba or mutt in the same production jail as datalevin. It is however a potential pain on developer machines or home user toys and may discourage people from adopting datalevin if they have to deinstall mutt or samba first. I personally use datalevin only embedded into my application, as I think of this as one of the big pros of the clojure ecosystem (though I might change my opinion on that next week). I am however working on a port to FreeBSD that allows to just type pkg install datalevin && service datalevin enable like one types pkg install pgsql && service pgsql enable. So maybe it would be a good idea to migrate the mdb_x tools to be dlmdb_x tools as well as have datalevin depend on dlmdb.a/dlmdb.so instead lmdb.so.

Huahai 2026-03-01T06:34:12.023469Z

Master branch is now up to date. Please see if it works for you.

magra 2026-02-21T09:41:03.185999Z

Thank you, I will look into the Cirrus CI path too. To build a native dtlvnative.jar we need a FreeBSD capable javacpp.jar which I can build locally but has not been released. JavaCPP seems not to release that often and I will send them more PRs for freebsd-arm. I might be using the word PORT strangly 😉 FreeBSD has three parts: Kernel, Base and Ports. The Portstree contains all the build-scripts to fetch, extract, configure, patch, build, stage, package and install a port. Buldservers run this whole tree and offer packages per release and per architecture. The stage and package steps make sure uninstall knows what you brought in and works correctly. As a FreeBSD user, you can go into any port directory and call make to build locally potentially while setting options, or you just type pkg install dtlvnative. On FreeBSD you will pkg install openjdk anyway so pkg install openjdk21 dtlvnative is no detour. At the moment I am working on FreeBSD ports of dlmdb and dtlvn (and for optional use datalevin itself) which depend on ports of usearch and javacpp. Current progress: • dlmdb port from lmdb to lmdb: https://github.com/datalevin/dlmdb/compare/main...markusalbertgraf:dlmdb:main • I have a working dlmd FreeBSD port which at the moment points at this fork • I have a working usearch FreeBSD port ready • I am working on a FreeBSD port of javacpp Todo: • complete javacpp port • PR to have dtlvnative depend on dlmdb instead of lmdb • dtlvnative port • datalevin port

👍 1

magra 2026-02-25T15:36:45.389499Z

@huahaiy I sent PRs to migrate lmdb to dlmdb. I built a local poudriere jail to build the dlmdb and dtlvnative ports. At the moment these point at my PRs.

❤️ 1

magra 2026-02-26T16:17:33.438699Z

@huahaiy I send a tiny PR to sync dtlvnative and dlmdb regarding the renaming. Since commit https://github.com/datalevin/dtlvnative/commit/60ad3de7a55d239eec4c7d80fe0dd9933ba48d18 "remove counters and samplers that do O(n) iterations" to dtlvnative, testing it with datalevin tests causes about 90 tests to throw because they miss dtlv_key_range_count_cap. To submit the Ports to FreeBSD I can 1. wait for dtlvnative and datalevin to be in sync again, or 2. Submit using a fork that puts the lmdb2dlmdb migration on top of an older commit of dtlvnative What is your planned timeframe for dtlvnative and datalevin to be in sync again? The question is do I wait or fork?

Huahai 2026-02-26T22:40:10.955569Z

I am in the final stage of finishing the WAL mode. It will be merged in master very soon. By then, dtlvnative and datalevin will be in sync. Before Monday.

❤️ 1

🎉 1

magra 2026-03-02T21:11:09.859059Z

Yes!! All test (except the migrations of course) pass!!! Thank you!!!

Huahai 2026-02-20T21:29:38.390359Z

BTW, the freebsd path you add to dtlvnative will not deploy a freebsd jar because there's no CI path to build and deploy it. Do you have a plan to do that?

Huahai 2026-02-20T21:31:43.937799Z

It seems that cirrus ci has freebsd vms, https://cirrus-ci.org/guide/FreeBSD/ you may want to add an cirrus-ci yaml file in dtlvnative project to build and deploy it.

Huahai 2026-02-20T21:32:17.854749Z

I will be happy to merge another PR for this.

Huahai 2026-02-19T20:43:35.662529Z

Sure. Good idea. PR welcome.

magra 2026-02-19T20:50:21.092899Z

Ok, I am on it.

🙏 1

Clojurians Log v2

datalevin