I’m happy to announce LogikalDB, which is an open source reactive logical database layer built on top of FoundationDB.
It’s basically an experimental querying and data layer for FoundationDB, where the querying engine is a microKanren based micro embedded logic programming language. It’s experimental, because it’s not released as an official maven package yet and also because we are looking for some early feedback about the layer.
The main design goal of the project was to find and create a foundational query layer that is easy to use and extend. We came up with this main goal, because we wanted to know if it’s even possible to find such a basic building block for querying engines or not.
Another interesting design goal that we came up with is the unified query and data model, which means that from a user perspective they behave the same way. For example this also means that you can even store your queries in the database itself.
We plan to improve and extend this layer and hopefully build up an ecosystem around it, so let me know what do you think about it.
If you are interested then you can find more information about the layer in the repository’s readme or in the examples folder if you like to read code more than documentation.
I did some experiments with microkaren. Can you explain how the data is stored in FDB? Possibly indicating the code that translate a dataset into data inside FDB.
Data is stored based on the entities that you can find in the GoalEntity.kt file. It’s just a bunch of data classes that represents the different Goals that you can find in this microKanren based system.
LogikalDB uses CBOR to convert these data structures to binary, so it can be stored in FDB.
The interaction with FDB is handled by the DatabaseHandler class.
The main LogikalDB interface connects these pieces together, so there is no magic in storing these kind of data.
The real magic happens when we need to evaluate this data representation by converting it into the typical microKanren functional representation.
LogikalDB is reactive, because it uses Kotlin Flow(Reactive Stream) to represent the “state stream” that microKanren systems are built on. You can think of Flow as kind of like a lazy stream that only gets evaluated when a terminal operation is run on it.
LogikalDB has been released on Maven Central, which means that you can use it easily in your kotlin projects.
Right now the project is kotlin only, because there is some work needed to make the project fully available for java projects.
Changes
The biggest change has been the improved query interface, which also started to look more like SQL.
So the syntax is the following in LogikalDB:
logikalDB
.read(<directory_path>, <table_name>) // Get data from db
.and() // Add your query constraints (works the same as a where clause in SQL)
.select(<variable_names>) // Select the varibales/fields that you are interested in
Note: Aggregations haven’t really been covered in the library yet, because it feels like they can be easily implemented on the client side, because a lot of java/kotlin container class already has built-in support for them.
Another notable change was that the examples folder moved into it’s own repository, which makes it easier to get started with LogikalDB and also helps in uncovering problems with the usability of the library. This means that you can just clone the repo and start playing with LogikalDB easily.
Roadmap
The biggest item on the roadmap is trying out if it makes sense to make LogikalDB optionally typed or not.
It’s on the roadmap, because the implementation of the cmp constraint in the standard library uses some runtime type checking that we could remove if using static types was an option in LogikalDB.
Second item is about supporting namespaces for variables. Right now this is an issue, because variables are global in LogikalDb so they can easily collide if you don’t use some prefix in the variable names.
Third item is about using a more database related naming. This would improve usability and would also make the explanations in the readme easier to understand.
Last item that I mentioned before is to make the project fully java compatible.
LogikalDB has been refactored to support typed database fields
Custom constraint creation system have been simplified, so you no longer need to do complex setup to create your own custom constraints
Standard library have been converted into typed one and have been covered with unit tests
Variable has been renamed to Field and Goal has been renamed to Constraint in the codebase in order to use more easier to understand database specific words
Roadmap:
The 0.4.0 release has been a pretty significant change in the codebase and I kind of feel like it stabilized and simplified the codebase a lot. For the next release I still plan to work on the usability of the library, because I feel like the developer experience is not there yet where it should be.
Overall I’m pretty happy with the state of the library because it feels like it improved a lot and also because I learned a lot during the development of this release.
