I’ve been thinking about writing a code analysis and refactoring tool that would expose facts like AST node info, expression typings, etc as queryable collections. To make this fast and interactive, you’d only compute the facts needed for a query and ideally incrementally maintain those as files change.<p>Rust used a Datalog library inside the borrow checker for this; I’d like to bring similar model to more languages so that some kinds of refactors or lints written as queries could potentially be shared between languages - for example, a lint rule that prohibits optional arguments to functions.<p>I wonder if GlueSQL would work naturally as this kind of “OSQuery for source code”.
Another "database toolkit" project that I've recently learned about is Apache DataFusion, also written in rust and uses Arrow memory format:<p><a href="https://github.com/apache/arrow-datafusion/blob/master/README.md" rel="nofollow">https://github.com/apache/arrow-datafusion/blob/master/READM...</a>
Just another embedded SQL engine.<p>There are SQLite(OLTP), DuckDB(OLAP) and some engine-based project like mentioned Apache Arrow(<a href="https://arrow.apache.org/)(OLAP)" rel="nofollow">https://arrow.apache.org/)(OLAP)</a>: Apache Arrow has many language implementations, some do not include the query engine(for example, Rust implementation, which depends on the DataFusion for more SQL-like analytics) in its own repo, but other do include(for example, C++).<p>There is a comprehensive benchmark by ClickHouse for OLAP but including kinds of embedding engines: <a href="https://benchmark.clickhouse.com/" rel="nofollow">https://benchmark.clickhouse.com/</a><p>The more interesting is that, in fact, we have not an embedded HTAP engine. One of my database products already implements 3/4 HTAP at the engine layer, but unfortunately it's still just a free software, not an open source implementation.
Note that persistent storage appears to rely on 'sled', and according to sled's github readme, sled's persistent storage format is going to change in the future so you would need to manually migrate any databases.
Seeing the examples, I start to wonder if it would be possible to support real sql syntax from within a rust macro, that maybe even has access to local variables like LINQ?