While playing with Prism and poking about with the idea of a datalog-like database, I got to thinking about how Prisms content-addressing might enable a nifty type of extension point.
Let's say you want to build a database which allows applications to store some form of logic alongside their data. Maybe it's a query, a function or some rules.
Whatever it is, you now need to invent/borrow some kind of language, along with a parser, runtime, versioning, tooling etc etc. This idea quickly spirals.
Alternatively (quite likely if me) you course correct, and build a lower level abstraction forcing logic back into client applications and abandoning the power you wanted to build into your database. However, the would-be developer now gets to use their language and tooling of choice with all its expressive power and ecosystem.
This may introduce a sort of version drift. The database and client code evolve independently even though the guarantees of the system span both.
Prism creates content-derived ids for all definitions (I think). Could one define the rules for a logic database in Prism code, then rather than serialising and sending them off to the database, just send and store the hash of the rule definition?
When later interacting with the database, it could just return the hash of the rules as part of a response. The client library would then locate, verify and run the corresponding code.
This would allow the database to specify an exact version of some behaviour without ever having to store or run it. In this way, the guarantees of the system could remain strong, while the deployment and development feels more natural.
Lots of things I havent answered. Can I select code by hash? Could I use this approach to have multiple concurrent versions of code deployed and allow the database to choose which is live? Is this a terrible idea?