sqlite-readers-writers
sea-query
sqlite-readers-writers | sea-query | |
---|---|---|
1 | 23 | |
1 | 1,019 | |
- | 3.7% | |
10.0 | 9.1 | |
over 1 year ago | 10 days ago | |
Rust | Rust | |
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sqlite-readers-writers
-
In pursuit of the best value US cloud provider
This has been posted and reposted continuously for a year and I still don’t understand the comparisons in the article. Either use SQLite across the board or use MySQL/Postgres across the board. Or do both. You can even model a self-managed rdbms install on the clouds that don’t have that turnkey offering. But mixing and matching makes no sense.
I’m a huge fan of SQLite and have open sourced some .NET stuff around it (eg https://github.com/neosmart/AspSqliteCache ) but learned a very expensive mistake in using it for an ASP.NET Core Project with the default pattern (i.e. with EF Core).
SQLite locks (tables or the entire db depending on configuration) upon write. If you use shared cache mode and WAL you can get very far with one write thread and many competing reads - depending on shared cache mode, WAL, and other options. I benchmarked the different configurations with one or more writing threads here to show how it scales: https://github.com/mqudsi/sqlite-readers-writers
But this approach is hard to model with EF Core. If you use the default request-scoped DI injected connection, you risk any writes upgrading the read lock to a write lock for the duration of the request. The better approach is to use the default request-scoped connection for RO operations and then request a scoped/transient DI connection for any write ops, but copying internal EF entity tracking state from one EF instance to another is tedious and fraught with issues. You’re at least able to work around this if you try to always keep in mind write transaction lifetimes, though.
The problem comes as soon as you need a “background service” in the sense of “an operation running independently of requests and parallel to them.” If that service needs a write lock for any amount of time, you’re suddenly going to be seeing write timeouts (since default behavior is to poll repeatedly until a write lock is obtained) and that is pretty much impossible to fix.
As one of the biggest advantages of using a resident executor like .NET or Java vs a per-request stateless option like PHP is that you can do stuff independent of requests, SQLite is tricky to use correctly in prod in this model.
The good news is that if you use the SQLite EF provider and run into this, it’s usually not too hard to switch to a real DB provider as a lot of the work is abstracted.
sea-query
-
Hey Rustaceans! Got a question? Ask here (8/2023)!
The main limitation of prepared statement is that you can only insert values, so you cannot dynamically construct the query depending on the parameters. For that, you can use a query builder such as sea-query, which should handle that.
-
Modern DB that works with sqlx?
I would say https://www.sea-ql.org is your best bet. It’s highly configurable and they also have tools for no bs orm and graphql! Very new, but there is 1.0 release and tonnes of documentation and cook books.
-
What's new in SeaQuery 0.28.0
[#508] Representing a identifier with &'static str. The IdenStatic trait looks like this:
-
What's new in SeaQuery 0.27.0
🎉 We are pleased to release SeaQuery 0.27.0! Here are some feature highlights 🌟:
-
Using Rust as my Backend
SeaORM or SeaQuery are also very good instead of diesel/sqlx
- Sea-query: A dynamic SQL query builder for MySQL, Postgres and SQLite
- GitHub - SeaQL/sea-query: A dynamic SQL query builder for MySQL, Postgres and SQLite
-
Celebrating 3,000+ GitHub Stars 🎉
SeaQL.org was founded back in 2020. We devoted ourselves into developing open source libraries that help Rust developers to build data intensive applications. In the past two years, we published and maintained four open source libraries: SeaQuery, SeaSchema, SeaORM and StarfishQL. Each library is designed to fill a niche in the Rust ecosystem, and they are made to play well with other Rust libraries.
-
What's new in SeaORM 0.9.0
Upgrade sea-query to 0.26
-
Introducing StarfishQL - visualizing the dependency network on crates.io
As the new member of the SeaQL family, it's a stellar example of what could be done with Rust and the SeaORM / SeaQuery / SeaSchema suite of tools. We couldn't be more excited to see applications being built on Rust and the SeaQL ecosystem!
What are some alternatives?
vfsstat.rs - Example sqlite3 Dynamic Loadable Extension in Rust - vfs and vtab modules - port of vfsstat.c
sqlx - general purpose extensions to golang's database/sql
rsqlite3 - sqlite3 Rewritten in RiiR Rust 🦀🦀🦀 /s
sea-orm - 🐚 An async & dynamic ORM for Rust
SqliteCache for ASP.NET Core - An ASP.NET Core IDistributedCache provider backed by SQLite
rust-postgis - postgis helper library.
rusqlite-model - Model trait and derive implementation for rusqlite
aws-sdk-rust - AWS SDK for the Rust Programming Language
doteur - Tool to automate the visualisation of SQL schemas from a SQL file
datafusion - Apache DataFusion SQL Query Engine
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
SaintCoinach - A .NET library written in C# for extracting game assets and reading game assets from Final Fantasy XIV: A Realm Reborn.