mirror of
https://github.com/diesel-rs/diesel.git
synced 2024-10-04 01:28:13 +03:00
A safe, extensible ORM and Query Builder for Rust
ccad1510c1
`infer_schema!` is woefully undertested. Really our tests for it at the moment are "we use it for our test suite so the cases our suite covers work". However, even though I defined `tinyint` == `Bool`, I wanted to make sure that `TINYINT(1)` was treated as bool as well, as I wasn't certain how SQLite handles limit/precision/scale. The answer is that it doesn't, and it's way looser about allowed type names than I had thought. The process listed at https://www.sqlite.org/datatype3.html is a literal description, and any possible string is a valid type. This adds tests for every example given on that page, plus a few extras. We create a table with as many of these fields as possible, and do a trivial roundtrip to make sure that it *actually* infers something we can deserialize from, and that we're not doing anything dumb. The new logic for type inference matches pretty closely to how SQLite handles things with a few exceptions: - "boolean" or types containing "tiny" and "int" are treated as bool - smallint and bigint are separated from int - float is separated from double - varchar is separated from text - We do not accept random unrecognized type names as numeric Unresolved Questions -------------------- This actually starts to make me a bit more nervous about our semantics with SQLite. If you're just using Diesel, everything is fine. However, you can definitely insert values that would fail to deserialize with so little constraints on the backend. I'm starting to wonder if we should truly embrace SQLite's definitions and map exactly to that, allowing only the following types: - BigInt - VarChar (yes, it's the ANSI text type but we treat VarChar as the "default" string type) - Binary - Double We're omitting numeric, as there's no observable difference in SQLite between the real affinity and the numeric affinity. This would have several *major* implications. Aside from not being able to use basic things like an `i32`, it would also mean that there is no boolean type, and no dates/times/datetimes. Functions for those do exist on the SQLite side though, so some of the interactions might get super janky. That said, Diesel's goal is not to abstract away the backend. These are the semantics of the backend chosen, and maybe we should go whole hog and embrace them. I'm still unsure. In the meantime, with our current semantics, this should improve the reliability of `infer_schema!` |
||
|---|---|---|
| .cargo | ||
| bin | ||
| diesel | ||
| diesel_cli | ||
| diesel_codegen | ||
| diesel_compile_tests | ||
| diesel_tests | ||
| migrations | ||
| .example.env | ||
| .gitignore | ||
| .travis.yml | ||
| CHANGELOG.md | ||
| code_of_conduct.md | ||
| LICENSE-APACHE | ||
| LICENSE-MIT | ||
| README.md | ||
A safe, extensible ORM and Query Builder for Rust
Diesel gets rid of the boilerplate for database interaction and eliminates runtime errors, without sacrificing performance. It takes full advantage of Rust's type system to create a low overhead query builder that "feels like Rust".
Getting Started
You can find an extensive Getting Started tutorial at http://diesel.rs/guides/getting-started. Guides on more specific features will be coming soon.
Code of conduct
Anyone who interacts with Diesel in any space including but not limited to this GitHub repository is expected to follow our code of conduct
License
Licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.