ob_dump_reader 0.1.0-beta.3

Minimal ObjectBox LMDB reader toolkit for Dart and Flutter: reads data.mdb directly through a bundled LMDB (build hook).

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning. Generated from the repo root's CHANGELOG.md at publish time — see that file if you're reading this in the published package and want the full picture across the other packages in this repo too.

0.1.0-beta.3 - 2026-10-27

Changed

• Breaking: one package now serves the Dart VM and Flutter. The native LMDB library is compiled by a Dart build hook (hook/build.dart, hooks + native_toolchain_c) from the vendored source in src/lmdb/ into a code asset, so dart run, dart test, flutter run/build/test and AOT release builds all resolve it the same way on Android, iOS, Linux, macOS and Windows -- nothing is downloaded. The LMDB bindings are now @Native (lib/src/lmdb_bindings.dart).
• Requires Dart SDK ^3.10.0 (build hooks / native assets).
• Reading (readObjectBoxRecords(), readToManyTargets()) now probes the native library first and throws an LmdbException that names the problem ("Could not load the native LMDB library ...") instead of an ArgumentError ("Couldn't resolve native function ...") from deep inside the first read.

Added

• Known limitation (documented in dart/README.md): inside the macOS App Sandbox LMDB's named POSIX semaphores are denied, so opening a store fails with "Operation not permitted"; the example is run unsandboxed on macOS in CI.
• The build hook checks the library it just built, so a bad build fails the build instead of the app at startup: the file must exist, export every mdb_* function the bindings call (the Windows DLL gets its exports from src/lmdb_exports_win.c: MSVC exports nothing by default) and, when the target is the machine doing the build, actually load and answer a call. Android libraries are linked 16 KB page aligned (Google Play requirement).
• dart/example: a small Flutter app that writes an ObjectBox-shaped store and reads it back. CI builds and runs it on every platform and as an offline Flatpak (see the CI entry below).
• CI: flutter test of the example on Linux/macOS/Windows; release builds of the example for Linux, macOS, Windows, Android and iOS, each checking that the library the hook compiled is in the bundle (Android: also 16 KB alignment and no libc++_shared.so dependency) and that the built app reads a store and, with the library removed from the bundle, fails fast with a clear error; an Android emulator job that loads the library on a device; a console-app check that reading throws a clear error when liblmdb is missing; a pub publish --dry-run job; and a manually started Flatpak workflow (flatpak.yml) that builds the example as an offline Flatpak for x86_64 and aarch64 with flutpak and runs it inside the sandbox.

Removed

• dart run ob_dump_reader:build (bin/build.dart, tool/build.dart, the executables: entry), the hand-written DynamicLibrary loader and its package_config.json lookup, and the CMake build of src/lmdb: the build hook replaces all of it.
• Dependency on path (no longer used).

0.1.0-beta.2 - 2026-10-27

Fixed

• The liblmdb shared library is found under flutter test on Flutter 3.47+: there Isolate.resolvePackageUriSync throws UnsupportedError, so the library placed by dart run ob_dump_reader:build was unreachable. As a last resort the loader now reads .dart_tool/package_config.json directly (local files only, no network), after the executable-relative lookup, so compiled and bundled builds are unchanged.

0.1.0-beta.1 - 2026-07-22

Changed

• Version bump only — republished in lockstep with flutter/py (see the intro above), no functional changes.

0.1.0-alpha.2 - 2026-07-06

Added

• dart run ob_dump_reader:build — compiles the vendored LMDB source into a shared library for the current desktop platform (Linux/macOS/ Windows), via a plain CMake configure+build. No network, no FetchContent, no prebuilt binary. Only needed for plain-Dart (non- Flutter) use; ob_dump_reader_flutter bundles its own build automatically as a real Flutter plugin.
• readToManyTargets() — resolves ObjectBox ToMany relation links directly from LMDB (not part of the FlatBuffers table flatc --dart output can decode).
• decodeFlex(), bytesToHex(), bytesToUuidString(), tryParseJsonString() — decode helpers for Flex fields and the Uuid/Int128/Decimal128/Bson/Json/JavaScript/JsonToNative ExternalPropertyType annotations, which flatc --dart output only gives you as raw bytes/strings. Mirrors ob-dump's own C++ decode exactly.

Changed

• No longer depends on dart_lmdb2 — replaced with a small, purpose-built dart:ffi binding over the vendored LMDB C source (src/lmdb/, LMDB_0.9.31 — the same commit ob-dump's own C++ core builds and has verified). Reasons, both confirmed empirically rather than assumed:
  • dart_lmdb2's own native-library path resolution (Isolate.resolvePackageUriSync()) throws UnsupportedError outright in a compiled AOT release build — reproduced with a real flutter build linux --release, copying only the output bundle to an isolated directory (no source project, no pub cache) and running it. Not Flatpak-specific: breaks every compiled Flutter Linux/Windows release build depending on it.
  • flutter_lmdb2 (the Flutter-plugin wrapper) has no Linux or Windows support at all as published — both platforms are commented out in its own pubspec.yaml.
  • This package's own loader (src/lmdb_native_library.dart) doesn't repeat either mistake: tries package: URI resolution first (unchanged dart run/flutter run behaviour), then falls back per platform to where each platform's own native-library bundling convention actually places the library (confirmed against the official flutter create --template=plugin_ffi scaffold, not guessed).
• readObjectBoxRecords() no longer copies to a temporary directory — reads the original files directly, in place. The copy was only ever needed because dart_lmdb2 required a write-capable LMDB environment just to register the root database handle; this package's own binding opens the environment itself MDB_RDONLY from the start (matching ob-dump's own C++ LmdbReader), which is exactly what LMDB's MVCC design is for: any number of readers can safely run alongside one concurrent writer, in any process, with zero risk to the original data.

Removed

• readObjectBoxRecordsUnsafe() / readToManyTargetsUnsafe() — no longer needed now that the safe, default functions read in place with no copy (see above); there was no longer a distinction for these to make.

0.1.0-alpha.0

Added

• readObjectBoxRecords() — walks an ObjectBox LMDB store and yields each record's raw FlatBuffers table bytes plus its entity id and object id. No FlatBuffers/schema knowledge; pair with flatc --dart output generated from ob_dump --fbs (see the parent ob-dump project).