PumpkinDB
Problem: PumpkinDB is too low-level
For most end-user cases, PumpkinDB is too "close to the metal" to be easily plugged into a business application, especially if "event sourcing" type of scenarios are considered.
Proposed solution: implement a higher level database on top of PumpkinDB
I am working on the first prototype of ViewDB, here's an excerpt from its README:
ViewDB
ViewDB is a database that allows inferring multiple, potentially overlapping (and even mutually inconsistent!) domain models from statements of facts.
At its heart, it is not too dissimilar from the concept of event sourcing, but it prioritizes late and lazy domain binding: the ability to produce the aforementioned models on-demand without replaying all events in a particular stream to produce a representation of some state, or even having a need to draw the lines between event categories in order to split them into different streams.
Facts (this name was chosen instead of "events" to further clarify their nature) are the source of truth in ViewDB and the principal entity type that gets persisted.
I've got some interesting ideas as to how everything can be simplified down to attributes and how this can lead to fluid yet explicit fact schemas.
The biggest issue here is IMO that projecting 'facts' to entities/models/whatever requires a lot of business logic.
So you need a (ideally strongly typed) language to define that business logic.
Any ideas on that front?
Yes, there has been a plan to introduce Typed PumpkinScript. Essentially a type checker for PumpkinScript. Just haven't got around to do that.
But PumpkinScript is way too low level for normal devs to write business logic in.
That is also very true. There were some conversations about building either transpilers for other "higher level" languages into [Typed] PumpkinScript and/or compiling to a common intermediate representation, which is yet to be done, but very necessary anyway.
I just published an overview of ViewDB's core ideas: https://github.com/ViewDB/ViewDB#readme
