Why not valid Rust as schema language? #50
playdohface
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
First of all: this looks very exciting!
When playing around, I couldn't help but notice that the schema definition is very close in syntax to the actual entity-struct generated from it:
becomes:
But there is a definitive cost to having our Entity-struct being generated code as opposed to hand-written, such as being able to
#[derive(Serialize)
directly on one and not the other.I understand, and am very much in favor of not wrapping everything up in proc-macros and calling it magic, and one of my main requirements for a good ORM is the ability to correctly intuit what it will generate from given DSL code, and override when I have to, which macros make very difficult.
But I'm left wondering why we need to have a schema definition language that is not also valid Rust?
In my opinion, this is as (if not more) ergonomical to read and write as the separate schema and contains all the information (I think the foreign_key annotation is even redundant on Todo here).
And then we can use the CLI to unlock all the impls and migrations for us, in ordinary and readable Rust that gets checked into version control, and perhaps can even be open to modification.
I think I've just described my dream ORM - the toasty vision seems very close already. 🏆
I am genuinely curious to learn why separating the schema definition from the Rust code would be preferable to this approach.
Beta Was this translation helpful? Give feedback.
All reactions