cozo VS blog

I can figure parts of it out from https://github.com/cozodb/cozo/blob/main/cozo-core/tests/air_routes.rs which is enough to get started

I've been keeping an eye on https://github.com/cozodb/cozo which is pretty close to something I've wanted, a sqlite version of datalog/datomic.

Finally, the one product I was extremely impressed with and felt was genuinely impressive as a database in general was cozodb.

Take a look at cozodb. It meets most of your goals and I've been really enjoying using it. It might give you some inspiration or something to contribute to.

Sure. They're called 'partials' sometimes. Useful if you want to rerender just part of a page. This is a pattern used by HTMX, a 'js framework' that accepts fragments of html in an http response and injects it into the page. This is good because it avoids the flash and state loss of a whole page reload. See the HTMX essay on template fragments for a more complete argument [0].

This is a go template for an interactive todos app [1] that I'm experimenting with. The html content of the entire page is present in one template definition which is split into 6 inline {{block}} definitions / "fragments". The page supports 5 interactions indicated by {{define}} definitions, each of which reuse various block fragments relevant to that interaction. I'm in the process of converting it to use embedded cozodb [2] queries which act as a server side data store. The idea here is that the entire 'app', including all html fragments, styles, http requests and responses, db schema, and queries are embedded into this single 100-line file.

[0]: https://htmx.org/essays/template-fragments/

[1]: https://github.com/infogulch/go-htmx/blob/master/templates/t...

[2]: https://github.com/cozodb/cozo

If anyone wants to try a FOSS vector-relational-graph hybrid database for more complicated workloads than simple vector search, here it is: https://github.com/cozodb/cozo/

About the integrated vector search: https://docs.cozodb.org/en/latest/releases/v0.6.html

It also does duplicate detection (Minhash-LSH) and full-text search within the query language itself: https://docs.cozodb.org/en/latest/releases/v0.7.html

HN discussion a few days ago: https://news.ycombinator.com/item?id=35641164

Disclaimer: I wrote it.

You are probably talking about this cozo.

This reminds me of a great blog post by Frank McSherry (Materialize, timely dataflow, etc) talking about how using the right tools on a laptop could beat out a bunch of these JVM distributed querying tools because... data locality basically.

https://github.com/frankmcsherry/blog/blob/master/posts/2015...

Oh, cool!

And yeah, licenses can be challenging and frustrating, especially the first time you release a major project.

I am really super excited by the idea of embedded Datalog in Rust. I run into a lot of situations where I need something that fits in that awkward gap between SQL and Prolog. I want more expressiveness, better composability, and better graph support than SQL. But I also want finite-sized results that I can materialize in bounded time.

There has been some very neat work with incrementally-updated Datalog in the Rust community. For example, I think Datafrog is really neat: https://github.com/frankmcsherry/blog/blob/master/posts/2018... But it's great to see more neat projects in this space, so thank you.

They used to but Frank McSherry (author of differential dataflow) wrote them a specialized version without all the dataflow infrastructure [1]. It's part of the rust-lang nursery [2] now but hasn't been updated in a while, so I'm not sure what happened to it.

[1] https://github.com/frankmcsherry/blog/blob/master/posts/2018...

[2] https://github.com/rust-lang/datafrog

Importantly, this doesn't just use memoization (it actually avoids having to spend memory on that), but rather uses operators (nodes in the dataflow graph) that directly work with `(time, data, delta)` tuples. The `time` is a general lattice, so fairly flexible (e.g. for expressing loop nesting/recursive computations, but also for handling multiple input sources with their own timestamps), and the `delta` type is between a (potentially commutative) semigroup (don't be confused, they use addition as the group operation) and an abelian group. E.g. collections that are iteratively refined in loops often need an abelian `delta` type, while monoids (semigroup + explicit zero element) allow for efficient append-only computations [0].

[0]: https://github.com/frankmcsherry/blog/blob/master/posts/2019...