B8 - executable code blocks with a real kernel: - worker/handler/kernel.cljs: one persistent SCI interpreter session per page, reused across block evaluations so defs/state survive between runs. Deliberately scoped to the same privileges the existing client-side single-shot evaluator already had (no shell/fs access, no call-api). - Run button + result display wired into block.cljs's code-block UI. - New :logseq.property.code/result and /executed-at properties (65.38). B9 - live notes: pages tagged #LiveNote that fetch external content on a refresh schedule and render it via the render-resource pipeline: - worker/handler/live_notes.cljs: per-block credential storage, scheduled refresh (Node-only), thread-apis for manual refresh and auth. - worker/handler/render_resource/live_note.cljs: reads back fetched content, watching [:entity block-uuid] for reactive invalidation. - New :logseq.class/LiveNote + :logseq.property.livenote/* properties (65.39). Bugs found and fixed along the way while actually exercising page creation through page-handler/create! for the first time in a test (previously only pure-fn tests existed for CalDAV/Event/Contact): - logseq-property-namespaces (property.cljs) was missing the citation/event/ contact/caldav/livenote namespaces, causing auto-create-ontology to treat already-built-in properties as new user idents. - outliner/page.cljs's build-page-tx always added the generic #Page tag even when the caller tagged with a built-in class that extends #Page, which malli-schema rejects as conflicting; it also lost the property type when building ref-typed property values for new pages, breaking non-:default types like :number. - entity-util/page? never recognized Event/Contact/LiveNote as pages (only Journal/Whiteboard/Tag/Property/Page had dedicated recognition), so pages tagged with those classes alone weren't treated as pages anywhere in the app; added built-in-page-child? alongside the existing per-class checks. - caldav.cljs's upsert-page! passed a bare keyword as a tag where an entity was required, and two error logs passed raw error objects to glogi that triggered runaway recursion in this test environment; both fixed.
Description
This library provides an API to the frontend(datascript) and backend(SQLite) databases from the Logseq app and the CLI. This library defines the core schema and fns for DB graphs. There are a few namespaces that also support file graphs for the graph-parser. This library is compatible with ClojureScript and with nbb-logseq to respectively provide frontend and commandline functionality.
API
This library is under the parent namespace logseq.db. It provides the following namespaces:
logseq.db- main public ns. Most often used by frontendlogseq.db.frontend.*- frontend namespaces for DB graphslogseq.db.sqlite.*- backend/sqlite namespaces for DB graphslogseq.db.common.*- frontend and backend namespaces for DB graphs
The following namespaces are used with file graphs via the graph-parser: logseq.db.common.order, logseq.db.frontend.entity-util and logseq.db.common.entity-plus.
Usage
See the frontend for example usage.
Dev
This follows the practices that the Logseq frontend follows. Most of the same linters are used, with configurations that are specific to this library. See this library's CI file for linting examples.
Setup
To run linters and tests, you'll want to install pnpm dependencies once:
pnpm install
This step is not needed if you're just running the application.
Testing
Testing is done with nbb-logseq and nbb-test-runner. Some basic usage:
# Run all tests
$ pnpm test
# List available options
$ pnpm test -H
# Run tests with :focus metadata flag
$ pnpm test -i focus
Datalog linting
Datalog rules for the client are linted through a script that also uses the datalog-parser. To run this linter:
bb lint:rules
Managing dependencies
The package.json dependencies are just for testing and should be updated if there is new behavior to test.
The deps.edn dependencies are used by both ClojureScript and nbb-logseq. Their versions should be backwards compatible with each other with priority given to the frontend. No new dependency should be introduced to this library without an understanding of the tradeoffs of adding this to nbb-logseq.