joaoh82/rust_sqlite

SQLRite - Simple embedded database modeled off SQLite in Rust

rust_sqlite's Issues

Introduce Slack / Discord / Libera ?

Hi, I would like to contribute. Is there a community chat for this project?

Cheers

Will this project continue? Will persistent database on disk be implemented?

Greetings Sir! Excellent project in first place, I wanted to query if you intent to continue it. It'd be nice to 've at least the '.open ' command finished, so we can learn how a persistent database binary file storage on disk would look like.

Simple SELECT queries (Single WHERE clause and no JOINS).

Simple SELECT queries

Expect

Simple SELECT queries (Single WHERE clause and no JOINS).

Recognition how to do it

1. recognising how it is done in sqllite.

Rethink of project logic

Hey,
I was just starting to implement the SELECT query of the engine and I guess I've been thinking about the overall approach. At the moment it seems to be very modular (which isn't actually bad when it comes to abstracting over the engine). Parse query -> Parse to structs -> Execute. I think we should remove the middle step and go straight to execution. This would mean fewer allocations along the line. So basically take sqlparser's output and just use that in execution
I'd love to know what you think.

Using WASM instead of custom virtual machine?

I was actually toying around with building a Rust database not too long ago & the interesting thought I had was about using WASM w/ a custom API instead of a VM to execute queries. The mental model I had was one of LLVM IR - that would make this suitable as a general database layer that's potentially accessible from any language. The JIT part of WASM is a nice "free" feature you get although I don't think it would meaningfully add performance but I think having a language-agnostic target API to build against could be interesting, letting any language target their queries against the runtime (i.e. write the database code in the language of your choice with domain-specific optimizations rather than using plain text SQL).

The open design question I didn't explore is what does the API look like & do you put the plan optimizer as part of the SQL layer or if you have the WASM API be the plan optimizer. I think the latter is probably the easiest to bring up while the former offers the largest opportunity for exploring greenfield ideas in this space.

I know there's exploration of integrating WASM for stored procedures, but you would get that implicitly for free if it was WASM at the lowest layers.

On the other hand, this could be a terrible idea. Wonder what your thought on this architecture is.