Repository navigation
Conversation
…ive`, and add workspace crate `rapidquery-macros`
Re-export dialects from rapidquery.dialect, add stubs, and fix the native submodule __name__/__module__ so classes live at rapidquery._core.dialect. Make dialect instances compare and hash by variant and repr as PostgreSQL(). Rename Python class names to DuckDB, PostgreSQL, SQLite, and MSSQL (Rust variants stay idiomatic).
stdlib json (1M runs): 4.5s -> 2.5s orjson (1M runs): 4.3s -> 0.3s
…abled by default)
Keep enum-vs-class shims only for dialects and serializers (src/dialect/py.rs, src/data_type/py.rs). Ident, Value, DataType, and SQL writers live as src modules. Python API is unchanged.
Drop PyIdent/PyValue/PyDataType newtypes. Keep PySqlDialect and PySerializer as the enum-vs-class shims. Unquote and Asterisk stay as marker pyclasses.
…stead of std::fmt::Write - We supported templates in some dialect fields, to improve customizing - We used `itoa` and `zmij` crates for converting floats and integers to &str - FastWrite helps us to control writing without being worry about write methods and unwraping useless `Result`s (Part of Python stubs and tests needs refactor)
…lect Refactor and optimize dialect with new Template struct
Switch to nightly version of Rust
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Based on the feedback I received and the experience I gained, the plan was to switch the library from using
sea-querytosqlparser-rs, but it wasn’t adaptable enough.The decision was made to implement our own custom query engine and take inspiration from existing libraries.
Why is this change needed?
Elimination of all Known Issues
By replacing the core from
sea-querywith a custom-built one, panic risks are gone. We can implement any feature quickly or fix any problem immediately without waiting for others to address it. I will develop the library carefully and thoroughly so that as few mistakes as possible remain.Support for more dialects
From the start, we can support over 10 dialects. Currently, 13 dialects have been implemented, though this number may be reduced to a maximum of 10 as the implementation is finalized.
Custom dialect support is also included, allowing you to create your own dialects (with some limitations).
Full control
The library can give you complete and unrestricted control over the queries you build, similar to existing Python query engines.
More complete and comprehensive features
I will try to cover most ASTs. The development priority is as follows: anything added must either be defined by ANSI SQL or supported by at least 3 dialects.
After implementing these, I’ll start covering additional cases as well...
Better performance
Since the query engine becomes fully custom, it can be adapted more closely to Python, eliminating some of the overhead we previously had. For example, with
sea-querywe had to first convertPyObjects to Rust types before generating SQL, but with the custom query engine we can convertPyObjects directly to SQL wherever needed.