Things that kept me from using surreal, some open ended questions for usage in rust

[m1212e]

Hi,

starting a backend rewrite in rust, I was looking for a db/orm solution. I always wanted to try surreal and heard a lot of good things about it. While playing around with it, I noticed some things I wanted to ask/give feedback about:

1. Is there some way of ensuring sync between the db schema and my structs/queries?
This is the most important aspect for me: When I have a table with an enforced schema, can I somehow ensure that it is in sync with my structs at build time? This thought comes from me using sqlx where you get compile time errors in case you write queries that are invalid, either syntactically or just not matching the current database schema. This is super helpful since you can worry less about breaking things since the compiler simply will prevent you from doing that. Also it may help in cases where the db schema just doesn't match the struct I wrote. When I'm prototyping, carelessly adding and removing fields, throwing around my datamodels it just is a nice thing to know that the tools I'm using will prevent me from shipping invalid queries :D

2. Migrations
When using a schemaful table, which is probably a good idea in the long run, we need some form of migrations. What is a common tool, library or way to approach this in rust? I took a look at https://github.com/odonno/surrealdb-migrations which looks promising, but I am just curious for other opinions on this. Do yo recommend on writing migrations by hand? What about applying them? Do you typically write the code you need to manage migrations yourself or is it recommended to use tools like the one above?

3. Ergonomics
I like writing SQL and SurrealQL by hand. But this isn't the case for everyone I (will) work with. And I cannot deny that having intellisense for auto completing queries while strongly typing and passing parameters for filtering, creating and updating things in my DB is a neat thing. Tools like Prisma for the Typescript world and SeaORM for rust enable that and I understand why people like their way of doing things. Meanwhile, the rust SDK is very cool, but also limited in functionality. Having actual functions to call instead of a string to write my query into (overlaps with my concerns in 1.) is not the most developer friendly way I can imagine. A simple typo can break the whole query, which may not happen very often but I see myself looking for the cause of an error for hours only to find out that I misspelled something. In combination with a lack of build time check of my query this is an actual dealbreaker for me.

I know implementing the things I asked for is a ton of work and I don't want to seem too demanding here, let me make this clear: SurrealDB is sooo cool and I'd really like to see it succeed. I just wanted to give some feedback on my first impressions with it and ask around, if I just overlooked things or misunderstand anything or if you are maybe currently working on this and maybe need help?

[AlexFrid]

Hey @m1212e!

Thanks for your feedback, these are things we have indeed been thinking about and have some plans for but as you mentioned are a ton of work, where most of our work has been on improving the core functionality before moving into all the supporting tooling that is needed as well.

ideas are always appreciated, specifically around your first question, sqlx is amazing in this regard, if use have some ideas around how to integrate SurrealQL, that would be amazing!

[m1212e]

I'm currently playing around with a few ideas. Do you by any chance have a module that can transform rust structs into SQL for schema generation? Or some reuseable logic in that regard?

[AlexFrid]

Hmm.. I don't think we any external api / modules for that currently, just what we use internally for parsing etc.

[AlbertMarashi]

+1 on having more dev tools, especially for schema syncing, and typing of queries - (in JS)

[j-hartshorn]

Would love to see something like sqlc for Surreal