using cue as database schema

[aep]

so i'm working on a document database. currently i'm using jsonschema which feels familiar but has terrible performance.
its validation is also way too constrained

instead i'm now looking at cue and kcl. kcl seems to be a natural fit because you can store the compiled schema into the db.
with cue the best i could replace "schemas" with is by having a not yet concrete value exported as AST. This seems extremely inefficient? I'd have to load the AST every time someone puts a concrete document into the db.

Maybe i'm not thinking about cue right yet. maybe someone has a super genious idea how to make this fit, or maybe abusing cue like this just isnt a good idea

[myitcv]

Hi @aep - there are various levels at which CUE could be used when it comes to database schemas. This is not an area where we are actively working, but the design of the CUE the language (both current and planned features) is very much done with this kind of use in mind.

Noting also @tvandinther wrote something on this recently: https://mioi.io/blog/posts/cue-relational-data-modelling/

So to probe a bit more on what you were thinking here:

• Are you looking to have CUE act as a validation layer before updates to the database?
• Are you looking to represent a data model in CUE, and then have that be translated to an SQL model with constraints?
• Something else?!

[aep]

Interesting read, thanks!
It's a completely new database directly supporting structured yaml inspired by etcd.

https://github.com/aep/apogy

cue seemed like a great way to design the data model around. However, I already abandoned the idea because cue is too constrained for modeling relations between documents.

Also the focus on the cue cli (vs allowing extension via golang) makes me uneasy about tight integration. Instead, cue is now used only to validate data only. It's a bit unfortunately because cue contains some ideas that could go further, but they're difficult to reuse with all the important bits being marked internal and only exposed via it's Cli.

[myitcv]

Thanks for providing more details. Sounds incredibly interesting!

It's a bit unfortunately because cue contains some ideas that could go further, but they're difficult to reuse with all the important bits being marked internal and only exposed via it's Cli.

Some of the ideas discussed in #165 touch on some of proposed language changes to CUE the language that would support CUE acting as a specification for a data model, a model that could be translated (automatically) into multiple low-level SQL/other formats. The query extension also hints out how we envisage the querying of data from CUE being abstracted from the underlying source.

The language, the tooling and the APIs as they exist today are not set in stone. CUE itself has not yet reached v1, and some of the APIs marked as internal are slated to be "made public". We are very open to making changes, and tend to do so based on real-world situations/problems.

Given the above, we would be more than happy to discuss your use case and requirements, and feed that into the query proposal and more. Please feel free to contact me by email or on Discord/Slack if you'd like to arrange something.