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.

from pumpkindb.

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?

from pumpkindb.

Yes, there has been a plan to introduce Typed PumpkinScript. Essentially a type checker for PumpkinScript. Just haven't got around to do that.

from pumpkindb.

Here's the issue on that: #141

from pumpkindb.

But PumpkinScript is way too low level for normal devs to write business logic in.

from pumpkindb.

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.

from pumpkindb.

I just published an overview of ViewDB's core ideas: https://github.com/ViewDB/ViewDB#readme

from pumpkindb.

i dont mind its low level. but i do mind of its lack of examples

from pumpkindb.