A safe, extensible ORM and Query Builder for Rust

Overview

A safe, extensible ORM and Query Builder for Rust

Build Status Gitter Crates.io

API Documentation: latest releasemaster branch

Homepage

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."

Supported databases:

  1. PostgreSQL
  2. MySQL
  3. SQLite

You can configure the database backend in Cargo.toml:

[dependencies]
diesel = { version = "<version>", features = ["<postgres|mysql|sqlite>"] }

Getting Started

Find our extensive Getting Started tutorial at https://diesel.rs/guides/getting-started. Guides on more specific features are coming soon.

Getting help

If you run into problems, Diesel has a very active Gitter room. You can come ask for help at gitter.im/diesel-rs/diesel. For help with longer questions and discussion about the future of Diesel, visit our discourse forum.

Code of conduct

Anyone who interacts with Diesel in any space, including but not limited to this GitHub repository, must follow our code of conduct.

License

Licensed under either of these:

Contributing

Before contributing, please read the contributors guide for useful information about setting up Diesel locally, coding style and common abbreviations.

Unless you explicitly state otherwise, any contribution you intentionally submit for inclusion in the work, as defined in the Apache-2.0 license, shall be dual-licensed as above, without any additional terms or conditions.

Comments
  • Async I/O

    Async I/O

    With futures-rs and tokio the Rust ecosystem recently got a whole new chapter in the async IO story. It would be pretty great for diesel to work with this as well.

    From an enduser standpoint, a straightforward API change would be to 'just' use an Async PgConnection instead of the regular PgConnection (DB specific for more efficient implementations?). All traits generic over Connection (e.g. LoadDsl) would get an associated type to determine if they are returning e.g. a QueryResult<T> or a Future<T>.

    discussion desired 
    opened by killercup 146
  • impliment upsert for SQLite

    impliment upsert for SQLite

    opened by h-michael 54
  • Installing diesel_cli on Windows : some assembly required

    Installing diesel_cli on Windows : some assembly required

    Hello

    I was about to do the Diesel tutorial, but had to do some unexpected work at the "install diesel_cli" step, in order to make diesel_cli actually compile.

    The command I wanted to run is: rustup run nightly cargo install diesel_cli

    My environment is a Windows 10 x64 with VS14 installed, as well as PostgreSQL 9.6 (installed with the official installer) and the SQlite .dll and .def that I manually downloaded and put into some folder.

    While I had several errors, they were all pretty similar to this one (missing .lib input files):

       Compiling diesel_cli v0.8.0
         Running `rustc D:\\Users\\Shtong\\.cargo\\registry\\src\\github.com-1ecc6299db9ec823\\diesel_cli-0.8.0\\src\\main.rs --crate-name diesel --crate-type bin -C opt-level=3 --cfg feature=\"postgres\" --cfg feature=\"default\" --cfg feature=\"sqlite\" --cfg feature=\"diesel\" -C metadata=29283389226be5db --out-dir D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release --emit=dep-info,link -L dependency=D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps --extern chrono=D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libchrono-7342810e34d1c30d.rlib --extern diesel=D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libdiesel-759af232b86b362b.rlib --extern clap=D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libclap-8f0c0e13919e3e65.rlib --extern dotenv=D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libdotenv-695bff8444756e3d.rlib -L D:\\Programs\\Sqlite3`
    error: linking with `link.exe` failed: exit code: 1181
      |
      = note: "D:\\Programs\\VisualStudio14\\VC\\bin\\amd64\\link.exe" "/LIBPATH:D:\\Programs\\VisualStudio14\\VC\\lib\\amd64" "/LIBPATH:C:\\Program Files (x86)\\Windows Kits\\10\\lib\\10.0.10240.0\\ucrt\\x64" "/LIBPATH:C:\\Program Files (x86)\\Windows Kits\\8.1\\lib\\winv6.3\\um\\x64" "/NOLOGO" "/NXCOMPAT" "/LIBPATH:D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\diesel.0.o" "/OUT:D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\diesel.exe" "/OPT:REF,ICF" "/DEBUG" "/LIBPATH:D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps" "/LIBPATH:D:\\Programs\\Sqlite3" "/LIBPATH:D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libchrono-7342810e34d1c30d.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libdiesel-759af232b86b362b.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libbyteorder-f3f7821512ca2fd0.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libtime-750bfdd52feafcb7.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libpq_sys-d9fc24829db90d4f.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\liblibsqlite3_sys-755891849c290f5c.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libnum-1fa4854b44bb6a54.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libnum_iter-50df698bc905252c.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libnum_integer-52fdddf28cd8e924.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libnum_traits-92bb90166cd1857c.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libdotenv-695bff8444756e3d.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libregex-19c946c0da62af0b.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libutf8_ranges-5c6a6dacba3be7ce.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libregex_syntax-c54ab5597cd8541d.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libaho_corasick-d1dfd931d7cac82f.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libmemchr-c555f740a543880f.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libclap-8f0c0e13919e3e65.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libunicode_segmentation-e3fd0169850011a0.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libterm_size-9fd23557733de795.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libvec_map-d843695eff67d492.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libbitflags-0e272044714c8076.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libunicode_width-bcfd50e6d35d16e0.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\liblibc-ad32fde1bd850538.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libansi_term-aa5dcc2affa8dc75.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libstrsim-b42a694875d9a3b0.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libthread_local-a3c0092e9fb6507d.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libthread_id-bcd46c79a620a618.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libkernel32-df86a08647459244.rlib" "D:\\Users\\Shtong\\AppData\\Local\\Temp\\cargo-install.6Y8hTMX3pHdT\\release\\deps\\libwinapi-0889532d327ff4e2.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liblibc-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librand-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcollections-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc_system-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_unicode-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-6eb85298.rlib" "D:\\Users\\Shtong\\.multirust\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-6eb85298.rlib" "pq.lib" "sqlite3.lib" "sqlite3.lib" "sqlite3.lib" "msvcrt.lib" "kernel32.lib" "ws2_32.lib" "userenv.lib" "shell32.lib" "advapi32.lib" "msvcrt.lib"
      = note: LINK : fatal error LNK1181: cannot open input file 'sqlite3.lib'
    
    
    error: aborting due to previous error
    
    

    What I had to do in order to successfully compile:

    • Set the SQLITE3_LIB_DIR envvar to the directory containing the sqlite3 dll. This was not required by diesel itself but by one of its dependencies, and the error message suggested to set that var, so I guess it's not that bad
    • Set LIB envvar to both the PostgreSQL lib directory, and the directory containing the Sqlite3 binaries. Required for link to find the required libraries
    • Generate the Sqlite3.lib file manually, since it's not contained in the windows precompiled library official download (can be made with link /lib /def:sqlite3.def /MACHINE:X64 in my case)
    • Rename (or copy) the libpq.lib file located in the PostgreSQL lib directory into pq.lib

    After compilation was done, I had to copy the following DLLs in my ~/.cargo/bin

    • sqlite3.dll
    • libpq.dll
    • api-ms-win-crt-heap-l1-1-0.dll
    • api-ms-win-crt-locale-l1-1-0.dll
    • api-ms-win-crt-math-l1-1-0.dll
    • api-ms-win-crt-runtime-l1-1-0.dll
    • api-ms-win-crt-stdio-l1-1-0.dll
    • api-ms-win-crt-string-l1-1-0.dll

    I'm not sure if Diesel was designed to build on Windows in the first place (I couldn't find any mention of platform-specific instructions or warnings), but these steps allowed me to build Diesel and successfully run the migrations.

    opened by Shtong 41
  • Could not compile diesel_cli

    Could not compile diesel_cli

    Setup

    Versions

    • Rust: rustc 1.33.0 (2aa4c46cf 2019-02-28)
    • Database: postgres
    • Operating System Ubuntu 18.04.1 LTS

    Feature Flags

    • diesel: postgres

    Problem Description

    Unable to install diesel_cli

    What is the actual output?

    cargo install diesel_cli --no-default-features --features postgres

        Updating crates.io index
      Installing diesel_cli v1.4.0
       Compiling proc-macro2 v0.4.27
       Compiling cc v1.0.32
       Compiling libc v0.2.51
       Compiling unicode-xid v0.1.0
       Compiling memchr v2.2.0
       Compiling syn v0.15.29
       Compiling autocfg v0.1.2
       Compiling byteorder v1.3.1
       Compiling unicode-xid v0.0.4
       Compiling rand_core v0.4.0
       Compiling num-traits v0.2.6
       Compiling pq-sys v0.4.6
       Compiling num-integer v0.1.39
       Compiling serde v1.0.89
       Compiling regex v0.2.11
       Compiling smallvec v0.6.9
       Compiling lazy_static v1.3.0
       Compiling rustc-demangle v0.1.13
       Compiling cfg-if v0.1.7
       Compiling ucd-util v0.1.3
       Compiling matches v0.1.8
       Compiling quote v0.3.15
       Compiling bitflags v1.0.4
       Compiling unicode-width v0.1.5
       Compiling utf8-ranges v1.0.2
       Compiling ansi_term v0.11.0
       Compiling percent-encoding v1.0.1
       Compiling vec_map v0.8.1
       Compiling remove_dir_all v0.5.1
       Compiling strsim v0.7.0
       Compiling backtrace-sys v0.1.28
       Compiling backtrace v0.3.14
       Compiling rand_chacha v0.1.1
       Compiling rand_pcg v0.1.2
       Compiling rand v0.6.5
       Compiling synom v0.11.3
       Compiling rand_core v0.3.1
       Compiling rand_jitter v0.1.3
       Compiling unicode-normalization v0.1.8
       Compiling thread_local v0.3.6
       Compiling regex-syntax v0.5.6
       Compiling unicode-bidi v0.3.4
       Compiling textwrap v0.10.0
       Compiling syn v0.11.11
       Compiling rand_xorshift v0.1.1
       Compiling rand_isaac v0.1.1
       Compiling rand_hc v0.1.0
       Compiling idna v0.1.5
       Compiling quote v0.6.11
       Compiling rand_os v0.1.3
       Compiling atty v0.2.11
       Compiling time v0.1.42
       Compiling aho-corasick v0.6.10
       Compiling derive-error-chain v0.10.1
    error: failed to compile `diesel_cli v1.4.0`, intermediate artifacts can be found at `/tmp/cargo-installAh6AoH`
    
    Caused by:
      Could not compile `derive-error-chain`.
    
    Caused by:
      process didn't exit successfully: `rustc --crate-name derive_error_chain /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/derive-error-chain-0.10.1/src/lib.rs --color always --crate-type proc-macro --emit=dep-info,link -C prefer-dynamic -C opt-level=3 -C metadata=0f314aedb4e0a6c9 -C extra-filename=-0f314aedb4e0a6c9 --out-dir /tmp/cargo-installAh6AoH/release/deps -L dependency=/tmp/cargo-installAh6AoH/release/deps --extern quote=/tmp/cargo-installAh6AoH/release/deps/libquote-6c11d4fe1d50bb75.rlib --extern syn=/tmp/cargo-installAh6AoH/release/deps/libsyn-cf3b6b9bbadaa925.rlib --cap-lints allow` (signal: 9, SIGKILL: kill)
    

    Checklist

    • [X] I have already looked over the issue tracker for similar issues.
    • [X] This issue can be reproduced on Rust's stable channel. (Your issue will be closed if this is not the case)
    opened by paulocsanz 35
  • Add a story for upsert

    Add a story for upsert

    This is currently a gap in our API. Both SQLite and PG support it, though I'm not sure we can do a backend agnostic abstraction. I'm fine with providing two backend specific abstractions for this case.

    opened by sgrif 34
  • Diesel Segfaults on host, but not development machine

    Diesel Segfaults on host, but not development machine

    Hello, I'm in the progress of writing a small discord bot using diesel. However my application seems to receive a segfault on my VPS host (uname -a: Linux ubuntu-512mb-fra1-01 4.4.0-67-generic #88-Ubuntu SMP Wed Mar 8 16:34:45 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux; its the smallest size of an digitalocean droplet). It does not do so on my development machine (uname -a: Linux charon 4.10.2-1-ARCH #1 SMP PREEMPT Mon Mar 13 17:13:41 CET 2017 x86_64 GNU/Linux)

    Within GDB I get the following message for the segfautl:

    Thread 1 "skellybot" received signal SIGSEGV, Segmentation fault.
    0x0000555555a4d5f7 in je_tcache_dalloc_small (binind=<optimized out>, ptr=0x7ffff1ca5880, tcache=0x7ffff1c0c000, tsd=<optimized out>, slow_path=<optimized out>)
    at /checkout/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/tcache.h:42
    

    bt gives me the following stacktrace:

    #0  0x0000555555a4d5f7 in je_tcache_dalloc_small (binind=<optimized out>, ptr=0x7ffff1ca5880, tcache=0x7ffff1c0c000, tsd=<optimized out>, slow_path=<optimized out>)
        at /checkout/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/tcache.h:422                                                                           
    #1  je_arena_dalloc (tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>, slow_path=<optimized out>)
        at /checkout/src/liballoc_jemalloc/../jemalloc/include/jemalloc/internal/arena.h:1370                      
    #2  je_idalloctm (is_metadata=false, tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>, slow_path=<optimized out>) at include/jemalloc/internal/jemalloc_internal.h:1055
    #3  je_iqalloc (tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>, slow_path=<optimized out>) at include/jemalloc/internal/jemalloc_internal.h:1079
    #4  ifree (slow_path=false, tcache=0x7ffff1c0c000, ptr=0x7ffff1ca5880, tsd=<optimized out>) at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1819
    #5  free (ptr=0x7ffff1ca5880) at /checkout/src/liballoc_jemalloc/../jemalloc/src/jemalloc.c:1922
    #6  0x00007ffff7bb09d9 in ?? () from /usr/lib/x86_64-linux-gnu/libpq.so.5
    #7  0x0000555555627670 in diesel::pg::connection::raw::{{impl}}::drop (self=0x7fffffff92e0)
        at /home/skeleten/.cargo/registry/src/github.com-1ecc6299db9ec823/diesel-0.11.4/src/pg/connection/raw.rs:95
    #8  0x00005555555e53e1 in drop::hc00e4affa891dcbd () at /checkout/src/libcore/iter/iterator.rs:139
    #9  0x00005555555e4411 in drop::h82bb99e6329dd1c6 () at /checkout/src/libcore/iter/iterator.rs:139
    #10 0x000055555560ee02 in skellybot::user_seen (ctx=0x7fffffffb478, uid=0x7fffffffa1c0) at /home/skeleten/Source/skeleten/skellybot/src/main.rs:139
    #11 0x000055555560de02 in skellybot::message_create_event (ctx=0x7fffffffb478, msg=Message = {...}) at /home/skeleten/Source/skeleten/skellybot/src/main.rs:113
    #12 0x000055555560c7ee in skellybot::run () at /home/skeleten/Source/skeleten/skellybot/src/main.rs:89
    #13 0x000055555560b5e7 in skellybot::main () at /home/skeleten/Source/skeleten/skellybot/src/main.rs:32
    #14 0x0000555555a44146 in std::panicking::try::do_call<fn(),()> () at /checkout/src/libstd/panicking.rs:454
    #15 0x0000555555a4b4fb in panic_unwind::__rust_maybe_catch_panic () at /checkout/src/libpanic_unwind/lib.rs:98
    #16 0x0000555555a44bf7 in std::panicking::try<(),fn()> () at /checkout/src/libstd/panicking.rs:433
    #17 std::panic::catch_unwind<fn(),()> () at /checkout/src/libstd/panic.rs:361
    #18 std::rt::lang_start () at /checkout/src/libstd/rt.rs:57
    #19 0x0000555555615fe3 in main ()
    

    The complete source code I'm runnning can be found under https://github.com/skeleten/skellybot/tree/ece2a04ec61eaa8a1e62ecc3997aa0b7e4e99c6a

    The Segfaults happens after receiving the first message which is processed here https://github.com/skeleten/skellybot/blob/ece2a04ec61eaa8a1e62ecc3997aa0b7e4e99c6a/src/main.rs#L111

    opened by skeleten 31
  • Proper depth tracking and robust broken transaction detection

    Proper depth tracking and robust broken transaction detection

    • Fixes the detection of errored transaction blocks in Postgres, without relying on the English version of a localized error message (related to #2123)
    • Fixes connections unable to open new transactions in Postgres after a commit fails due to an INITIALLY DEFERRED constraint or trigger (which is quite dangerous as this breaks connection pools and is NOT detected by r2d2's SELECT 1 check)
    opened by Emm 29
  • Following `diesel` sqlite example fails with 1.0.0-beta1

    Following `diesel` sqlite example fails with 1.0.0-beta1

       Compiling diesel v1.0.0-beta1 (https://github.com/diesel-rs/diesel?rev=821c840d0c8dccd37ee5f3554304d16c7064ea0a#821c840d)
       Compiling diesel v1.0.0-beta1
       Compiling native-tls v0.1.4
       Compiling tokio-tls v0.1.3
       Compiling hyper-tls v0.1.2
       Compiling egg-mode v0.11.0
       Compiling infer_schema_internals v1.0.0-beta1
       Compiling infer_schema_macros v1.0.0-beta1
       Compiling diesel_infer_schema v1.0.0-beta1 (https://github.com/diesel-rs/diesel?rev=821c840d0c8dccd37ee5f3554304d16c7064ea0a#821c840d)
       Compiling twook v0.1.0 (file:///home/callen/work/twook)
    error: unexpected end of macro invocation
      --> src/main.rs:18:5
       |
    18 |     infer_schema!("dotenv:DATABASE_URL");
       |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       |
       = note: this error originates in a macro outside of the current crate
    
    error: aborting due to previous error
    
    error: Could not compile `twook`.
    
    To learn more, run the command again with --verbose.
    Makefile:9: recipe for target 'build' failed
    make: *** [build] Error 101
    

    Expanded macro invocation error

     -Z external-macro-backtrace`
    error: unexpected end of macro invocation
     --> <infer_schema macros>:3:14
      |
    1 | | ( $ database_url : expr ) => {
      | |____________________________________^
    2 |   mod __diesel_infer_schema {
    3 |   # [ derive ( InferSchema ) ] # [
      |  ______________^
    src/main.rs:18:5: 18:42 note: in this expansion of infer_schema! (defined in <infer_schema macros>)
    <infer_schema macros>:3:14: 3:25 note: in this expansion of #[derive(InferSchema)]
    
    error: aborting due to previous error
    

    The following should be a minimal repro from my main.rs:

    #[macro_use]
    pub extern crate diesel;
    #[macro_use]
    extern crate diesel_infer_schema;
    #[macro_use]
    extern crate dotenv;
    
    mod common;
    
    use common::tokio_core::reactor;
    use egg_mode::tweet::Tweet;
    use diesel::prelude::*;
    use dotenv::dotenv;
    use std::env;
    
    infer_schema!("dotenv:DATABASE_URL");
    
    [package]
    name = "twook"
    version = "0.1.0"
    
    [dependencies]
    chrono = "0.4.0"
    egg-mode = "0.11.0"
    diesel = { git = "https://github.com/diesel-rs/diesel", rev = "821c840d0c8dccd37ee5f3554304d16c7064ea0a", features = ["sqlite"] }
    diesel_infer_schema = { git = "https://github.com/diesel-rs/diesel", rev = "821c840d0c8dccd37ee5f3554304d16c7064ea0a", features = ["sqlite"] }
    dotenv = "0.9.0"
    futures = "*"
    tokio-core = "0.1.10"
    
    opened by bitemyapp 29
  • Issue 786 mysql ssl support

    Issue 786 mysql ssl support

    This PR aims to add ssl connection support for MySQL backend, which is requested in the issue #786 . At this stage it allow setting of mysql option MYSQL_OPT_SSL_MODE only. The connection could be established with MYSQL_OPT_SSL_MODE set to SSL_MODE_DISABLED, SSL_MODE_PREFERRED and SSL_MODE_REQUIRED.

    Tested with DATABASE_URL='mysql://***?ssl_mode=(disabled|required|preferred)' cargo test --manifest-path diesel/Cargo.toml --features mysql --no-default-features mysql

    https://dev.mysql.com/doc/c-api/8.0/en/mysql-options.html https://dev.mysql.com/doc/c-api/8.0/en/c-api-encrypted-connections.html

    opened by p-alik 28
  • Clarification on `update`

    Clarification on `update`

    So far update is the hardest to wrap my head around, and I was hoping for some clarification/guidance.

    In the context of an HTTP API, with a users table that looks like:

    table! {
        users {
            id -> Serial,
            first_name -> VarChar,
            last_name -> VarChar,
            email -> VarChar,
        }
    }
    

    how would you go about implementing a Users#update action?

    My first instinct is to have something like:

    #[changeset_for(users)]
    pub struct UserChanges {
        id: i32,
        first_name: Option<String>,
        last_name: Option<String>,
        email: Option<String>,
    }
    
    fn update(req: SomeHTTPReq) -> SomeHTTPRes {
      let changeset = UserChanges {
        first_name: req.body.get("first_name"),
        // etc
      }
    
      changeset.save_changes(&connection)
    }
    

    Such that you end up updating whatever valid params the user sends, but that requires having Nullable columns in the table macro, when the columns aren't actually nullable.

    Keep up all the great work!

    hole in api discussion desired 
    opened by mcasper 28
  • INTEGER PRIMARY KEY in SQLite

    INTEGER PRIMARY KEY in SQLite

    Diesel deduces the a column's type as BigInt if it's declared as BIGINT in the database. This is generally fine in SQLite because INTEGER and BIGINT are synonyms, but INTEGER PRIMARY KEY is treated differently and is always 64-bit according to https://sqlite.org/autoinc.html. Moreso, BIGINT PRIMARY KEY AUTOINCREMENT is not accepted.

    It might be a good idea to detect these columns and use BigInt for them. Note that the SQLite documentation says that INTEGER PRIMARY KEY is special only for tables that aren't declared with WITHOUT ROWID, but BIGINT PRIMARY KEY is still not allowed even when using that.

    opened by lnicola 27
  • Intermittent test failure for `intervals_match_pg_values_f64` testcase

    Intermittent test failure for `intervals_match_pg_values_f64` testcase

    Setup

    Versions

    • Rust: 1.60
    • Diesel: master branch
    • Database: doesn't matter
    • Operating System Ubuntu 20 @ WSL

    Problem Description

    Every now and then, while running tests, I will get a panic in this function

    thread 'pg::expression::extensions::interval_dsl::tests::intervals_match_pg_values_f64' panicked at '[quickcheck] TEST FAILED. Arguments: (29757356.223255634)', /home/tomo/.cargo/registry/src/github.com-1ecc6299db9ec823/quickcheck-1.0.3/src/tester.rs:165:28`
    

    What are you trying to accomplish?

    Run tests - bin/test

    Checklist

    • [x] This issue can be reproduced on Rust's stable channel. (Your issue will be closed if this is not the case)
    • [x] This issue can be reproduced without requiring a third party crate

    I can get this test to pass by rerunning the test script (sometimes it takes few tries to get it to work). I have zero idea what might be the case. FWIW this also shows up on a Macbook Pro @ Ventura MacOS with same Rust + Diesel version combo.

    tests 
    opened by czotomo 2
  • Drop GAT workarounds

    Drop GAT workarounds

    What it does:

    • Migrates GatWorkarounds to actual GATs

    Good to know:

    • Trait ConnectionSealed is kept to keep the feature gate around the Connection implementation.
    • I had to keep the associated type on RowFieldLifetimeHelper in order to express FieldRet without the lifetime of Row
    • This increases the minimal rust version from 1.60.0 to 1.65.0
    opened by Elrendio 9
  • print_schema.rs throws error for MySQL when enum present in schema

    print_schema.rs throws error for MySQL when enum present in schema

    Setup

    Versions

    • Rust:: 1.64
    • Diesel: 2.0.1
    • Database:: MySQL 8
    • Operating System: MacOS

    Feature Flags

    • diesel: postgres,mysql,sqlite

    Problem Description

    Trying to test my crate https://github.com/adwhit/diesel-derive-enum.

    I have a very simple schema to run against mysql (running in a docker container).

    CREATE TABLE simple (
      id SERIAL PRIMARY KEY,
      some_value ENUM('foo', 'bar', 'baz_quxx') NOT NULL
    );
    

    This is valid mysql, see https://dev.mysql.com/doc/refman/8.0/en/enum.html.

    When I execute diesel-cli I get an error:

    $ diesel --database-url mysql://root:[email protected]:3306/db migration run

    Encountered unknown type for Mysql: enum
    thread 'main' panicked at 'internal error: entered unreachable code: Mysql only supports a closed set of types.
                             If you ever see this error message please open an issue at https://github.com/diesel-rs/diesel containing a dump of your schema definition.', diesel_cli-2.0.1/src/print_schema.rs:313:17
    note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
    

    The same problem came up here: https://github.com/diesel-rs/diesel/discussions/3378 - unresolved.

    Checklist

    • [x] This issue can be reproduced on Rust's stable channel. (Your issue will be closed if this is not the case)
    • [x] This issue can be reproduced without requiring a third party crate
    bug 
    opened by adwhit 1
  • Add

    Add "delete" ability to `diesel_dynamic_schema::Table`

    This draft PR is meant to add "delete" capabilities to diesel_dynamic_schema::Table. Once it's working fine, this code should work:

        let users = diesel_dynamic_schema::table("users");
        let id = users.column::<Integer, _>("id");
    
        diesel::delete(users.filter(id.eq(42)))
            .execute(connection)
            .unwrap();
    

    Also, I would like to implement the truncate table statements, but it's currently not working (I need to implement diesel::query_builder::IntoUpdateTarget for diesel_dynamic_schema::Table).

    I would like to see if the CI complains with the new changes.

    opened by Razican 0
Releases(v2.0.2)
  • v2.0.2(Oct 11, 2022)

  • v2.0.1(Oct 7, 2022)

    This is a bugfix release containing the following fixes:

    • Fixed an issue with diesel_cli generating incompatible type names for the generate_missing_sql_type_definitions feature on PostgreSQL
    • Fixed an issue how diesel_cli handles sqlite urls while checking if a given database exists
    • Fixed an issue with PgConnection becoming unusable after hitting a database error in certain situations
    • Fixed an issue with diesel generating invalid SQL for certain INSERT … ON CONFLICT queries
    • Fixed diesel_derives generating code that triggers the disabled by default unused_qualifications lint

    This release includes updated versions of diesel, diesel_cli and diesel_derives

    Source code(tar.gz)
    Source code(zip)
  • v2.0.0(Aug 29, 2022)

    Diesel 2.0.0 contains the contributions of more than 130 people. More than 1700 commits were submitted over a span of 3 years.

    As part of this release we introduced numerous new features and rewrote large parts of the internal structure. Check out our changelog for a complete list of changes. As this is a new major Diesel release it contains a number of breaking changes. Checkout our migration guide for details about how to handle those breaking changes.

    This release contains the following parts:

    • diesel 2.0.0-rc.0
    • diesel_derives 2.0.0-rc.0
    • diesel_migrations 2.0.0-rc.0
    • diesel_cli 2.0.0-rc.0
    • diesel_dynamic_schema 0.2.0-rc.0

    This release marks a first prerelease of the upcoming Diesel 2.0 release. We ask you for your help to finalise the release. Checkout the "Timeline for a Diesel 2.0 release" section for details about how you can help us finishing the release.

    Features

    As a highlight Diesel 2.0.0 adds support for the following features:

    • Fully type checked GROUP BY support
    • Support for table aliasing
    • Support for defining select clauses via a corresponding type
    • Support for UNION/INTERSECT queries

    Support for GROUP BY clauses

    Diesel 2.0 adds support for GROUP BY clauses for select queries.

    This means queries like the following one will just work.

     users::table.inner_join(posts::table)
        .group_by(users::id)
        .select((users::name, count(posts::id)))
    

    As this is the case for all other Diesel built-in query dsl, this construct is fully checked at compile time. This means Diesel will ensure that the GROUP BY clause is valid for the current query and it will also ensure that expressions appearing inside of your SELECT clause will match the aggregation rules provided by the current GROUP BY clause.

    Support for table aliasing

    Diesel 2.0 adds support for table aliasing. This enables users to write queries, where a table appears more than once in the corresponding FROM clause. For this Diesel provides a Diesel::alias! macro that allows to define new alias for existing tables.

    The following query demonstrates the support for this feature:

    // Define new table alias for the existing `users` table
    let users1 = diesel::alias!(schema::users as user1);
    
    // Use the corresponding alias inside any existing query
    users::table
        .inner_join(users1.on(users::id).eq(users1.field(users::id))))
        .select((users::id, users::name, users1.field(users::name)))
        .order_by(users1.field(users::id))
    

    Again all of this is checked at compile time. So similar to a normal table, columns from aliases are only allowed to appear if the corresponding query actually uses the alias.

    Implied selection via the new Selectable trait

    Diesel 2.0 features a new Selectable trait and derive that lets users declare that a type expects a certain kind of select clause. The major use case for this feature is to ensure that columns from a specific query are always requested in the right order for a corresponding type implementing Queryable. This also works for complex queries involving joins or other kinds of nesting.

    #[derive(Queryable, Selectable)]
    struct User {
        id: i32,
        name: String,
    }
    
    let first_user = users.select(User::as_select()).first(connection)?;
    

    Diesel enforces at type system level that once you provided such a select clause via User::as_select() you are only allowed to construct this type from the returned result of the corresponding query. This means there is no need to specify the User type twice in the query above.

    Support for UNION/INTERSECT/EXCEPT queries

    Diesel 2.0 extents the query builder to support query combinations via UNION/INTERSECT/EXCEPT. This allows you to easily chain multiple queries together as long as they return fields of the same type. Queries like the following one are now supported:

     users.select(user_name.nullable())
        .union(animals.select(animal_name).filter(animal_name.is_not_null()))
    

    As always this is checked at compile time to reject invalid queries, like for example that ones containing select clauses with different fields.

    Call for Participation

    The release of Diesel 2.0 does not only include the features listed above, but also marks the point where the following things can be provided by third party crates:

    • Custom QueryDsl extensions to support previously unsupported SQL features. Checkout diesel_full_text_search for an example
    • Alternative query dsl implementations reusing the existing Connection infrastructure
    • Custom Connection implementations for existing backends
    • Custom Connection and Backend implementations for previously unsupported backends. Checkout diesel-oci for an example.

    We encourage our community to try out those features. Especially we would like to see experimentation around:

    • Previously unsupported database backends
    • Pure rust implementations of existing backend implementations. Checkout this and this discussion for starting points.
    • Alternative query dsl implementations. Checkout this discussion as starting point.

    Please get in touch with us for pointers, help and details.

    Input for Future Roadmap

    With the release of Diesel 2.0 the planing for our next releases start. Hopefully they will not take as long as Diesel 2.0. We are looking for input on which features are wanted by our community. Please open a discussion thread with your idea in our discussion forum.

    Weiznich will work on improving error messages for trait heavy crates based on a Rust Foundation Project Grant. This work will hopefully improve error messages for Diesel as well. If you are aware of bad error messages please submit a minimal example here.

    Thanks

    As part of this release we would like to welcome @Ten0 as part of the diesel core team.

    Thank you to everyone who helped make this release happen through bug reports, and discussion on Gitter. While we don't have a way to collect stats on that form of contribution, it's greatly appreciated.

    In addition to the Diesel core team, 141 people contributed code to this release. A huge thank you to:

    • Alessandro Menezes
    • Alexander 'z33ky' Hirsch
    • Alexei Pastuchov
    • Alice Ryhl
    • Amila Welihinda
    • Andre Braga Reis
    • Andreas Runfalk
    • Andrew Safigan
    • Andrew Speed
    • Andy Russell
    • Artem Vorotnikov
    • Arve Seljebu
    • Billy Chan
    • Blas Rodriguez Irizar
    • Bryan Henry
    • Callym
    • Caroline Glassberg-Powell
    • Cassie Jones
    • Chenxi Yuan
    • Chris Eckhardt
    • Chris Hanks
    • Chris Maddox
    • Chris West (Faux)
    • Clouds Flowing
    • Corentin Henry
    • Daniel Buse
    • Danilo Bargen
    • David Teller
    • David Tulig
    • DebugSteven
    • Diggory Blake
    • Dmitriy Pleshevskiy
    • Dusty Mabe
    • DrVilepis
    • EclipsedSolari
    • Emile Fugulin
    • Emm
    • Emmanuel Surleau
    • Erlend Langseth
    • Felix Watts
    • Filip Gospodinov
    • Garrett Thornburg
    • Giorgio Gambino
    • Grégory Obanos
    • Hal Gentz
    • Han Xu
    • Heliozoa
    • Henk van der Laan
    • Henry Boisdequin
    • Hirokazu Hata
    • Iban Eguia (Razican)
    • Igor Raits
    • Ivan Tham
    • JR Heard
    • Jean SIMARD
    • Jeremy Stucki
    • Jiří Sejkora
    • jigaoqiang
    • Joel Parker Henderson
    • John Brandt
    • Jonas Platte
    • Jonas Schievink
    • Joshua Koudys
    • Juhasz Sandor
    • Justice4Joffrey
    • Katharina Fey
    • Kevin King
    • Kevin Kirchner
    • Khionu Sybiern
    • Kitsu
    • Koisell
    • Kononnable
    • Leonardo Yvens
    • Lukas Markeffsky
    • Maccesch
    • Marc-Stefan Cassola
    • Martell Malone
    • Martijn Groeneveldt
    • Martin Nordholts
    • Matthew Kuo
    • Matthieu Guillemot
    • Mcat12
    • Meven
    • Mike Cronce
    • Mr Ceperka
    • Nafiul Islam
    • Nathan Papapietro
    • Nicholas Yang
    • Oliver Cooper
    • Otto Castle
    • Pankaj Jangid
    • Paolo Barbolini
    • Paul Le Corre
    • Paul Martensen
    • Pavan Kumar Sunkara
    • Paweł Przeniczny
    • Philip Trauner
    • Raphael Arias
    • Roman
    • Ryan Leckey
    • Sarthak Singh
    • Scott Driggers
    • Sean Klein
    • Simon Ertl
    • Spencer Taylor
    • Steven Chu
    • Storm Timmermans
    • Sébastien Santoro
    • Takayuki Maeda
    • Thomas Constantine Moore
    • Thomas Eizinger
    • Thomas Etter
    • Tom MacWright
    • Tuetuopay
    • Urhengulas
    • Vanio Begic
    • WebeWizard
    • William Myers
    • Yin Jifeng
    • Yuki Okushi
    • Zane Duffield
    • blackghost1987
    • czotomo
    • dchenk
    • ejc Drobnič
    • gorbit99
    • hasezoey
    • hi-rustin
    • kevinpoitra
    • kpcyrd
    • matthew-dowdell
    • ode79
    • ropottnik
    • telios
    • theredfish
    • zoewithabang
    • Zhenhui Xie
    • Émile Fugulin
    • κeen
    • 二手掉包工程师
    • 棒棒彬_Binboy
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-rc1(Jul 22, 2022)

    We are happy to announce the release of Diesel 2.0.0 RC1

    This release contains a number of fixes and improvements compared to the previous 2.0.0 RC0 release.

    Notably the following fixes and improvements are included:

    • A fix for an issue preventing connection reuse with the built-in r2d2 integration
    • Support for types from the ipnet crate
    • Support for loading values via libpq's row by row mode
    • Improvements to error messages generated by #[derive(Insertable)] for the case of type mismatches

    This release hopefully marks the last prerelease before a stable 2.0.0 release. We plan to release the final 2.0.0 soon after this, as long no other blocking issues are found.

    Thank you to everyone who helped make this release happen through bug reports, and discussion on Gitter. While we don't have a way to collect stats on that form of contribution, it's greatly appreciated.

    In addition to the Diesel core team, 8 people contributed code to this release. A huge thank you to:

    • Chris Eckhardt
    • Emile Fugulin
    • Iban Eguia Moraza
    • Jean SIMARD
    • Martin Nordholts
    • Otto Castle
    • Sean Klein
    • Steven Chu
    Source code(tar.gz)
    Source code(zip)
  • v2.0.0-rc0(Apr 22, 2022)

    Diesel 2.0.0-rc.0

    This release marks the first release candidate for the upcoming Diesel 2.0 Release.

    Diesel 2.0.0 contains the contributions of more than 130 people. More than 1700 commits were submitted over a span of 3 years.

    As part of this release we introduced numerous new features and rewrote large parts of the internal structure. Check out our changelog for a complete list of changes. As this is a new major Diesel release it contains a number of breaking changes. Checkout our draft migration guide for details about how to handle those breaking changes.

    This release contains the following parts:

    • diesel 2.0.0-rc.0
    • diesel_derives 2.0.0-rc.0
    • diesel_migrations 2.0.0-rc.0
    • diesel_cli 2.0.0-rc.0
    • diesel_dynamic_schema 0.2.0-rc.0

    This release marks a first prerelease of the upcoming Diesel 2.0 release. We ask you for your help to finalise the release. Checkout the "Timeline for a Diesel 2.0 release" section for details about how you can help us finishing the release.

    Features

    As a highlight Diesel 2.0.0 adds support for the following features:

    • Fully type checked GROUP BY support
    • Support for table aliasing
    • Support for defining select clauses via a corresponding type
    • Support for UNION/INTERSECT queries

    Support for GROUP BY clauses

    Diesel 2.0 adds support for GROUP BY clauses for select queries.

    This means queries like the following one will just work.

     users::table.inner_join(posts::table)
        .group_by(users::id)
        .select((users::name, count(posts::id)))
    

    As this is the case for all other Diesel built-in query dsl, this construct is fully checked at compile time. This means Diesel will ensure that the GROUP BY clause is valid for the current query and it will also ensure that expressions appearing inside of your SELECT clause will match the aggregation rules provided by the current GROUP BY clause.

    Support for table aliasing

    Diesel 2.0 adds support for table aliasing. This enables users to write queries, where a table appears more than once in the corresponding FROM clause. For this Diesel provides a Diesel::alias! macro that allows to define new alias for existing tables.

    The following query demonstrates the support for this feature:

    // Define new table alias for the existing `users` table
    let users1 = diesel::alias!(schema::users as user1);
    
    // Use the corresponding alias inside any existing query
    users::table
        .inner_join(users1.on(users::id).eq(users1.field(users::id))))
        .select((users::id, users::name, users1.field(users::name)))
        .order_by(users1.field(users::id))
    

    Again all of this is checked at compile time. So similar to a normal table, columns from aliases are only allowed to appear if the corresponding query actually uses the alias.

    Implied selection via the new Selectable trait

    Diesel 2.0 features a new Selectable trait and derive that lets users declare that a type expects a certain kind of select clause. The major use case for this feature is to ensure that columns from a specific query are always requested in the right order for a corresponding type implementing Queryable. This also works for complex queries involving joins or other kinds of nesting.

    #[derive(Queryable, Selectable)]
    struct User {
        id: i32,
        name: String,
    }
    
    let first_user = users.select(User::as_select()).first(connection)?;
    

    Diesel enforces at type system level that once you provided such a select clause via User::as_select() you are only allowed to construct this type from the returned result of the corresponding query. This means there is no need to specify the User type twice in the query above.

    Support for UNION/INTERSECT/EXCEPT queries

    Diesel 2.0 extents the query builder to support query combinations via UNION/INTERSECT/EXCEPT. This allows you to easily chain multiple queries together as long as they return fields of the same type. Queries like the following one are now supported:

     users.select(user_name.nullable())
        .union(animals.select(animal_name).filter(animal_name.is_not_null()))
    

    As always this is checked at compile time to reject invalid queries, like for example that ones containing select clauses with different fields.

    Timeline for Diesel 2.0

    We consider this release candidate of Diesel 2.0 as feature complete. Before finally releasing a stable 2.0 release we want to address the following points:

    • Updating the guides on our web page to use the new Diesel 2.0 release
    • Improve the migration guide to cover missed details or changes
    • Improve our documentation to include more details on new features

    You can help us rounding up this release by:

    • Updating your code to the RC release and report problems here
    • Help us improving the documentation by submitting reports and improvements
    • Help us porting our guides to the new release by submitting a PR here

    Thanks

    As part of this release we would like to welcome @Ten0 as part of the diesel core team.

    Thank you to everyone who helped make this release happen through bug reports, and discussion on Gitter. While we don't have a way to collect stats on that form of contribution, it's greatly appreciated.

    In addition to the Diesel core team, 134 people contributed code to this release. A huge thank you to:

    • Alessandro Menezes
    • Alexander 'z33ky' Hirsch
    • Alexei Pastuchov
    • Alice Ryhl
    • Amila Welihinda
    • Andre Braga Reis
    • Andreas Runfalk
    • Andrew Safigan
    • Andrew Speed
    • Andy Russell
    • Artem Vorotnikov
    • Arve Seljebu
    • Billy Chan
    • Blas Rodriguez Irizar
    • Bryan Henry
    • Callym
    • Caroline Glassberg-Powell
    • Cassie Jones
    • Chenxi Yuan
    • Chris Hanks
    • Chris Maddox
    • Chris West (Faux)
    • Clouds Flowing
    • Corentin Henry
    • Daniel Buse
    • Danilo Bargen
    • David Teller
    • David Tulig
    • DebugSteven
    • Diggory Blake
    • Dmitriy Pleshevskiy
    • Dusty Mabe
    • EclipsedSolari
    • Emile Fugulin
    • Emm
    • Emmanuel Surleau
    • Erlend Langseth
    • Felix Watts
    • Filip Gospodinov
    • Garrett Thornburg
    • Giorgio Gambino
    • Grégory Obanos
    • Hal Gentz
    • Han Xu
    • Henk van der Laan
    • Henry Boisdequin
    • Hirokazu Hata
    • Iban Eguia (Razican)
    • Igor Raits
    • Ivan Tham
    • JR Heard
    • Jeremy Stucki
    • Jiří Sejkora
    • Joel Parker Henderson
    • John Brandt
    • Jonas Platte
    • Jonas Schievink
    • Joshua Koudys
    • Juhasz Sandor
    • Justice4Joffrey
    • Katharina Fey
    • Kevin King
    • Kevin Kirchner
    • Khionu Sybiern
    • Kitsu
    • Koisell
    • Kononnable
    • Leonardo Yvens
    • Lukas Markeffsky
    • Maccesch
    • Marc-Stefan Cassola
    • Martell Malone
    • Martijn Groeneveldt
    • Matthew Kuo
    • Matthieu Guillemot
    • Mcat12
    • Meven
    • Mike Cronce
    • Mr Ceperka
    • Nafiul Islam
    • Nathan Papapietro
    • Nicholas Yang
    • Oliver Cooper
    • Otto Castle
    • Pankaj Jangid
    • Paolo Barbolini
    • Paul Le Corre
    • Paul Martensen
    • Pavan Kumar Sunkara
    • Paweł Przeniczny
    • Philip Trauner
    • Raphael Arias
    • Roman
    • Ryan Leckey
    • Sarthak Singh
    • Scott Driggers
    • Sean Klein
    • Simon Ertl
    • Spencer Taylor
    • Steven Chu
    • Storm Timmermans
    • Sébastien Santoro
    • Takayuki Maeda
    • Thomas Constantine Moore
    • Thomas Eizinger
    • Thomas Etter
    • Tom MacWright
    • Tuetuopay
    • Urhengulas
    • Vanio Begic
    • WebeWizard
    • William Myers
    • Yin Jifeng
    • Yuki Okushi
    • Zane Duffield
    • blackghost1987
    • czotomo
    • dchenk
    • ejc Drobnič
    • gorbit99
    • hasezoey
    • hi-rustin
    • kevinpoitra
    • kpcyrd
    • matthew-dowdell
    • ode79
    • ropottnik
    • telios
    • theredfish
    • zoewithabang
    • Émile Fugulin
    • κeen
    • 二手掉包工程师
    • 棒棒彬_Binboy
    Source code(tar.gz)
    Source code(zip)
  • v1.4.8(Sep 20, 2021)

    This release fixes an incompatibility between features passed to diesel and diesel_migrations while using cargos new resolver feature (resolver = "2") which will become the new default with the upcoming Rust 2021 edition

    Source code(tar.gz)
    Source code(zip)
  • v1.4.7(Jun 8, 2021)

  • v1.4.6(Mar 5, 2021)

  • v1.4.5(Jun 9, 2020)

    Fixed

    • Update several dependencies
    • Fixed an issue where transactions that would fail to commit would leave the connection in a broken non-committed non-rolled-back state.
    • Fix a bug that result in leaking sockets/file descriptors on failed connection attempts for postgresql
    • Fix an incompatibility with newer libmysqlclient versions
    • Remove some potential harmful usages of mem::uninitialized
    Source code(tar.gz)
    Source code(zip)
  • v1.4.4(Mar 23, 2020)

    Fixed

    • Update several dependencies
    • Fixed a bug with printing embedded migrations

    As part of this release also updated versions of migration_internals and migration_macros are published.

    Source code(tar.gz)
    Source code(zip)
  • v1.4.3(Oct 11, 2019)

    Fixed

    • Updated several dependencies
    • Fixed an issue where the postgresql backend exploits implementation defined behaviour
    • Fixed issue where rustdoc failed to build the documentation
    • diesel_derives and diesel_migrations are updated to syn 1.0
    Source code(tar.gz)
    Source code(zip)
  • v1.4.0(Jan 21, 2019)

    New Features

    In contrast to the last release most changes in this release are minor or internal. We've added support for newer versions of some dependency crates (libsqlite-sys, uuid, ipnetwork).

    Diesel CLI got a command line flag to check if a generated schema matches the already existing one. This is useful for CI setups to check there if the committed generated schema file matches the committed migrations.

    We've added support for the diesel_mange_updated_at('table_name') SQL function on SQLite. This function handles the setup of an trigger that automatically updates the updated_at column on update operations.

    Additionally several helpers were added to support the deserialisation of tuples and composite types on PostgreSQL.

    As always, a full list of changes can be found it in the changelog

    Thanks

    Thank you to everyone who helped make this release happen through bug reports, and discussion on Gitter. While we don't have a way to collect stats on that form of contribution, it's greatly appreciated.

    In addition to the Diesel core team, 29 people contributed code to this release. A huge thank you to:

    • Aleksey Ivanov
    • Andrew Speed
    • Carlos Diaz-Padron
    • Daniel Silverstone
    • Dirkjan Ochtman
    • Dominik Sander
    • Eyal Kalderon
    • Galuh Sahid
    • Hirokazu Hata
    • Jake Goulding
    • Jo Liss
    • Josh Leeb-du Toit
    • Kevin Stenerson
    • kpcyrd
    • Marcus Stollsteimer
    • Matej Stuchlik
    • Nikita Sivakov
    • notryanb
    • Rasmus Kaj
    • Richard Petrie
    • Rotem Yaari
    • Ryan Leckey
    • Sergio Benitez
    • Simon Heath
    • Stephen Muss
    • Trinh Hoang Anh
    Source code(tar.gz)
    Source code(zip)
  • v1.3.3(Sep 12, 2018)

    This is a small bugfix release, addressing an issue with MySQL 8.0. The behavior of the C API in libmysqlclient changed in this version of MySQL, causing problems when a connection pool was used with Diesel.

    If you are not using MySQL, or are on a version older than 8.0, this release does not affect you.

    Source code(tar.gz)
    Source code(zip)
  • v1.3.2(Jun 14, 2018)

    This release contains two major bugfixes. This release fixes the behavior of unsigned types on MySQL, and a compile time issue caused by the use of #[sql_name] in sql_function! with no return type. This release only affects users who are using unsigned types on MySQL, or who had code which failed to compile with 1.3.1.

    Source code(tar.gz)
    Source code(zip)
  • v1.3.0(May 22, 2018)

    New Features

    This release includes a couple of major changes to how Diesel projects are developed. In the past, we've had 2 ways to generate schema.rs. A procedural macro called infer_schema!, and a CLI command diesel print-schema. We've recommended using the CLI command for a long time, but infer_schema! was still useful for early prototypes.

    At the beginning of a project, your database schema changes much more frequently. It's extremely annoying to have to remember to run a second command after running your migrations.

    Diesel CLI 1.3 now supports a configuration file to customize its behavior. One of the new capabilities this provides is the ability to automatically regenerate schema.rs whenever you run or revert a migration. This means you no longer have to remember to run diesel print-schema when things change.

    Because of this, we are deprecating diesel_infer_schema. 1.3 will be the final release of that crate. However, diesel_infer_schema 1.3 will continue to work with diesel until at least Diesel 2.0. You can see all of the capabilities of the new configuration file at http://diesel.rs/guides/configuring-diesel-cli.

    This release also includes a complete redesign of the sql_function! macro. The new syntax is significantly closer to normal Rust. For example, what used to be written as:

    sql_function! {
        lower, lower_t, (x: Text) -> Text,
        "Here are the docs for `lower`
    It's awkward to make multiline"
    }
    

    Can now be written as:

    sql_function! {
        /// Here are the docs for `lower`
        /// It's just a normal doc comment.
        fn lower(x: Text) -> Text;
    }
    

    The new form also supports much more than the old one, including aggregate functions, function renaming, and generic functions. Things like MAX could previously not be expressed with sql_function!. However, now the definition looks like this:

    sql_function! {
        #[aggregate]
        fn max<ST: SqlOrd + IntoNullable>(expr: ST) -> ST::Nullable;
    }
    

    Finally, the redesigned sql_function! supports user defined functions on SQLite. SQLite differs from other databases, in that custom functions aren't defined in SQL. Instead you give it a C function pointer to use for the body. With Diesel, you can just give us any Rust closure that takes appropriate argument types, and we'll handle gluing that to SQLite for you.

    You can find examples for all of this in the docs for sql_function!.

    In addition to the headline features, this release includes a ton of quality of life changes including expanded support for locking clauses, more global support for mathematic operators, and more. As always, for a full list of changes you can find it in [the changelog].
    [the changelog]: https://github.com/diesel-rs/diesel/blob/v1.3.0/CHANGELOG.md

    Thanks

    Thank you to everyone who helped make this release happen through bug reports, and discussion on Gitter. While we don't have a way to collect stats on that form of contribution, it's greatly appreciated.

    In addition to the Diesel core team, 12 people contributed code to this release. A huge thank you to:

    • Aleksey Ivanov
    • Christopher Brickley
    • David Reid
    • Diggory Blake
    • Graham Turner
    • Katharina
    • Matt Kraai
    • Nick Babcock
    • Richard Petrie
    • Simon Dickson
    • Sunrin SHIMURA
    • Thierry Berger
    Source code(tar.gz)
    Source code(zip)
  • v1.2.0(Apr 7, 2018)

    This release contains several long awaited features.

    We've re-introduced the ability to use bind params with the sql function, in a way which is harder to mis-use. This functionality was present prior to 1.0, but was removed when sql_function was added over concerns about its use with the rest of the query builder. Recent developments have proved those concerns to be valid, but this new API fills that niche. Thanks to @notryanb for taking the lead on this feature.

    We've also added the ability to insert from a select statement (e.g. queries in the form of INSERT INTO table (...) SELECT .... This is a feature request that has come up repeatedly since release, and we're happy to finally bring it to you. We've also added alternate forms of our insert API which feel better when used with select statements. You can find the full details in the CHANGELOG.

    Finally, we've rewritten our custom dervies from scratch to take advantage of new diagnostic tools in recent versions of nightly Rust. If you turn on the unstable feature of Diesel on a nightly compiler, you'll find that you get dramatically improved error messages from our derives. For the best error messages, you should also set RUSTFLAGS="--cfg procmacro2_semver_exempt".

    Additionally, as of this release, Diesel is now powered by the blockchain. Because it's 2018 and that's how it works now I guess. See the CHANGELOG for full details.

    In addition to the headline features, there were a ton of features that we don't have time to mention here. As always, for a full list of changes you can find a full list in the CHANGELOG.

    Thanks

    Thank you to everyone who helped make this release happen through bug reports, and discussion on Gitter. While we don't have a way to collect stats on that form of contribution...

    In addition to the Diesel core team, 14 people contributed code to this release. A huge thank you to:

    • Alex Kitchens
    • Andrew Weiss
    • Arun Kulshreshtha
    • Brandur
    • EloD10
    • Jacob Chae
    • Jordan Petridis
    • Josh Leeb-du Toit
    • Kerollmops
    • Mathias Svensson
    • Ryan Blecher
    • Sander Maijers
    • Seth Larson
    • YetAnotherMinion
    Source code(tar.gz)
    Source code(zip)
  • v1.1.1(Jan 16, 2018)

    This release fixes a minor issue with our r2d2 support. In 1.1 we recommend that people access r2d2 via diesel::r2d2. However, r2d2 has a type called Error, which was shadowed by our own type called Error in that same module, making it inaccessible. This release adds an alias PoolError to point at r2d2::Error.

    Thanks to YetAnotherMinion for working on this release.

    Source code(tar.gz)
    Source code(zip)
  • v1.1.0(Jan 15, 2018)

    Improved Support for Adding New Types

    The primary focus of this release was improving the ergonomics of adding support for new types in Diesel.

    For implementing new SQL types, we've added #[derive(SqlType)] which implements many traits that you need to implement for every SQL type. See the documentation for HasSqlType for details on this derive.

    For implementing new mappings, we've added #[derive(FromSqlRow)] and #[derive(AsExpression)]. These derives will replace the majority of the boilerplate that was previously required when supporting new types. Adding support for new types in Diesel 1.1 should only require implementing FromSql and ToSql. The derives will handle the rest.

    We've also provided FromSql impls for *const str and *const [u8]. Due to the design of FromSql, we can't provide impls for &str and &[u8] without a breaking change. However many impls just need to parse a string or some bytes, and don't need the allocation that would come from String or Vec<u8>. This will require unsafe code to use, but should make certain implementations more efficient.

    Finally, we've restructured how our serialize/deserialize modules are structured, and provided type aliases to make implementations of FromSql and ToSql more consise.

    r2d2_diesel is Now Part of Diesel

    Finally, this release merges r2d2_diesel into Diesel itself. The main benefit of doing this is that we can implement Connection for PooledConnection, removing the need for explicit &* when using r2d2. This should also help to prevent version mismatches when changing Diesel versions.

    To use the new r2d2 support, remove r2d2 and r2d2_diesel from your Cargo.toml. Add the r2d2 to your enabled features on diesel. Replace extern crate r2d2 with pub use diesel::r2d2. Replace any r2d2_diesel:: with diesel::r2d2::.

    Thanks

    In addition to the headline features, there were dozens of smaller additions which should make using Diesel even better! As always, you can check the CHANGELOG for a full list of changes in this release.

    In addition to the Diesel core team, 8 people contributed to this release. A huge thank you to:

    • Ashe Connor
    • Chris Pick
    • Evan
    • Georg Semmler
    • MarcManiez
    • Martin Lindhe
    • Oliver Schneider
    • Ryan Blecher
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0(Jan 2, 2018)

    We didn't quite make it for 2017, but Diesel 1.0 is finally here! There are no changes between Diesel 1.0 and 1.0.0-rc1.

    1.0.0 marks stability for Diesel. While there are many more features that will be added in the future, there will be no breaking changes from this point forward without a major version bump (which we do not anticipate happening for many years).

    A lot has happened since Diesel 0.1 was released over 2 years ago. While it would be impossible to list every major change that has happened since then, here are a few highlights:

    • Expanded from a PostgreSQL specific library to supporting SQLite and MySQL
    • Went from nightly-only to nightly-optional to working purely on stable Rust
    • diesel print-schema replaced infer_schema! as the go-to way to infer your database schema.
    • Added support for a significant portion of SQL queries which could not be represented in 0.1

    It's been a great honor to watch this community grow and thrive as this library has developed. I look forward to continuing to evolve Diesel, and seeing how far it can go.

    In addition to the Diesel core team, 98 people have contributed to Diesel. A huge thank you to everyone who made this and every prior release possible:

    • Adam Perry
    • Adrian Perez de Castro
    • Alex Alvarez
    • Alex Kitchens
    • Alexey Zabelin
    • Andrew Lazarus
    • Andrew Ryan Lazarus
    • Arnar Mar Sig
    • Barosl Lee
    • Blake Pettersson
    • Bob
    • Boris-Chengbiao Zhou
    • Brandon W Maister
    • Cameron Alexander
    • Cengiz Can
    • Christopher Brickley
    • Cyryl Płotnicki
    • Daniel Durante
    • Danilo Bargen
    • David Szotten
    • Derek Prior
    • Dimiter Petrov
    • Dorian Scheidt
    • Enether
    • Eric Kidd
    • Erich Cordoba
    • FliegendeWurst
    • Flux Xu
    • Garrett Squire
    • Georg Semmler
    • Graham Grochowski
    • JD Gonzales
    • Jake Goulding
    • Jakob Gillich
    • James Kominick
    • Jethro Beekman
    • Jim McGrath
    • Jimmy Cuadra
    • John Gallagher
    • Jordan
    • Josh Holmer
    • Jovansonlee Cesar
    • Katrina Brock
    • Kieran
    • Konstantinos Sideris
    • Lance Carlson
    • Lauri Apple
    • Maciej
    • Maciej Dziardziel
    • Mark Catley
    • Martijn de Haan
    • Mathieu Rochette
    • Matt Casper
    • Maxime “pep” Buquet
    • Michael Macias
    • Michael Stock
    • Mike Piccolo
    • Mrmaxmeier
    • Patrick Fernie
    • Paul Lange
    • Peter Marheine
    • Pyry Kontio
    • Rasmus Kaj
    • Richard Dodd
    • Robert Balicki
    • Robert Maloney
    • Ruben De Smet
    • Ryan Blecher
    • Sam Phippen
    • Sebastian Blei
    • Sergio Benitez
    • Severen Redwood
    • Sharad Chand
    • Sid Ngeth
    • Stu Black
    • Sunrin SHIMURA (keen)
    • Tamir Duberstein
    • Taryn Hill
    • Tess Griffin
    • Tim Brooks
    • Tobias Schottdorf
    • Tom Houlé
    • Tshepang Lekhonkhobe
    • Will Murphy
    • William Murphy
    • benaryorg
    • bippityboppity
    • debris
    • derekdreery
    • jacob
    • jethrogb
    • kardeiz
    • king6cong
    • klieth
    • pfernie
    • theduke
    • wangcong
    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-rc1(Dec 23, 2017)

    Happy holidays!

    This release contains no major code changes. There are a handful of minor bug fixes (the most notable being that SQLite no longer panics when we receive SQLITE_BUSY), but most changes are related to ensuring that our API documentation renders better.

    We do not expect any further changes to the codebase of any kind (other than the version number) between this release and 1.0.0. Assuming no critical issues are found with this release candidate, the code as it exists at this point will be released as 1.0.0 on 2017-12-30.

    Source code(tar.gz)
    Source code(zip)
  • v1.0.0-beta1(Dec 4, 2017)

    This release contains 2 major changes from 0.99.0. The first is not news, we have removed all deprecated code from the codebase. However, this release also contains some major restructuring of the query_dsl module.

    Traits related to the construction of queries, such as SelectDsl, FilterDsl, etc. Have been merged into a single QueryDsl trait. Traits related to the execution of queries, such as ExecuteDsl and LoadDsl have been merged into a single RunQueryDsl trait. The individual method traits still exist under the query_dsl::methods module, but they are no longer exported from prelude.

    Though we promised there would be no significant changes other than documentation, during our process of documenting this module, it became clear that making this change would make discovering how to use Diesel's query builder dramatically easier. It also gives us a much more centralized place to document these logically grouped methods. While we do not expect this change to break many apps, it is significant enough to warrant an early release.

    Most applications should not need to care about this change. Code which is just doing use diesel::prelude::* and calling these methods will continue to work with no changes (though error messages will be improved if you make a mistake).

    However, if you had code that was implementing QueryFragment or Query, and expected to be able to call .execute, .load, or similar on it (such as the Pagination helper in crates.io), you will need to add impl<Conn> RunQueryDsl<Conn> for YourType.

    If you have code that is calling query builder methods generically (e.g. if you have where T: FilterDsl<Something>, you will likely need to explicitly import things from query_dsl::methods

    In addition to those changes, there are some minor improvements to #[derive(QueryableByName)] which we had planned on releasing as 0.99.2.

    Stability

    With this release, 0.99.x will only receive bug fixes and security patches. No new features will be backported to that branch. However, 0.99 can be considered our first "LTS" release. While we have not yet determined what exactly that means for Diesel, you can be assured that release line will continue to be supported for as long as there is demand.

    We do not plan on having a 1.0.0.beta2, but there may be additional minor breaking changes in that release if it is needed. If there are any code changes between now and 1.0.0, even non-breaking ones, we will have a release candidate before the final release.

    Looking Ahead

    As with 0.99.0, we expect that the only significant change between this release and 1.0.0 will be documentation. We expect that the final release of 1.0.0 will be before the end of the year.

    Our only blocker for a final 1.0 release continues to be documentation. There is a lot of work to do before the end of the year. We need help from the community to reach our goal of releasing this year. If you're interested in helping out, join the impl period working group channel.

    Source code(tar.gz)
    Source code(zip)
  • v0.99.0(Nov 29, 2017)

    This release is by far the largest Diesel has ever had. It serves 2 purposes. You can consider this release to be a beta for 1.0. However, 1.0 will have an important significant difference. Anything that is deprecated as of this release will not be present in the 1.0 release. This includes functions which were newly deprecated in 0.99. We know this may introduce a migration burden for some people, so we will continue to support the 0.99 line with bug fixes as long as there is demand and it is reasonable to do so.

    Headline Features

    This release is mainly focused on ergonomics. Our main new feature is the sql_query function. This is a new API which behaves similarly to sql, but it is entirely focused on cases where you want to write the entire query yourself. The main difference from sql is that you do not need to specify the return type of the query, and values are fetched by name rather than by index. This feature is still early, and there's a lot of features still to come (specifically evolving #[derive(QueryableByName)], but we think this feature will ease a lot of pains for cases where Diesel doesn't quite do what you need.

    Additionally, you can now use tuples for inserts the same as you can for updates. If you've ever wanted to insert a row with just 1 or 2 values, and been annoyed that you needed a struct that you're only using in this one place, this feature will make you happy. We'll have new guides highlighting this feature soon.

    Additionally, this release comes with a ton of quality of life features. Many of these changes are focused around making it easier to introduce line breaks naturally in your code. For example, .filter is now implemented on UpdateStatement, meaning you can write update(foo).filter(bar) instead of update(foo.filter(bar)). We've also introduced new APIs for insert and PG upsert which will have similar readability improvements.

    Breaking Changes

    This release includes more deprecations than any release prior. In particular, insert has been deprecated, along with our entire PG upsert API. All deprecations in this release have direct replacements, which will lead to code which formats much more nicely. It should be a mostly mechanical replacement for most apps. See the CHANGELOG file for details.

    Growing the Team

    With this release, we'd like to welcome several new members to the Diesel committer team. @weiznich, @notryanb, and @katrinabrock you've all done excellent work and we're very excited to officially welcome you to the team!

    Additional Thanks

    In addition to the Diesel core and committer teams, 10 people contributed to this release. A huge thank you to:

    • Adam Perry
    • Alex Kitchens
    • Alexey Zabelin
    • Arnar Mar Sig
    • Bob
    • Jordan
    • Lauri Apple
    • Maxime “pep” Buquet
    • William Murphy
    • bippityboppity

    Our only remaining blockers from this release and 1.0 are documentation changes, and having this tested in the wild. Thank you to every one of our users for your support, and we look forward to Diesel 1.0 by the end of the year!

    Source code(tar.gz)
    Source code(zip)
  • v0.16.0(Aug 24, 2017)

    This release contains some changes to how joins work with Diesel, which we wanted to release as far in advance of 1.0 as possible. With this release, #[belongs_to] no longer generates the code required to join between two tables. The macro joinable! must be invoked instead. However, if you are using infer_schema! or diesel print-schema, these invocations will be generated based on the foreign keys in your database.

    Also included in this release is the ability to rename columns. This is most useful when your columns conflict with Rust keywords. See the changelog for details.

    In addition to the Diesel core team, 11 people contributed to this release. A huge thank you to:

    • Alex Alvarez
    • Georg Semmler
    • Graham Grochowski
    • JD Gonzales
    • Lance Carlson
    • Maciej
    • Robert Balicki
    • Sharad Chand
    • Taryn Hill
    • debris
    • klieth
    Source code(tar.gz)
    Source code(zip)
  • v0.15.2(Jul 28, 2017)

    This is a minor bugfix release which addresses an issue with encoding of BigDecimal objects with PostgreSQL. Diesel would previously incorrectly encode certain numbers resulting in a runtime error.

    Source code(tar.gz)
    Source code(zip)
  • v0.15.0(Jul 23, 2017)

    This is a minor release containing a few quality of life features. We were originally planning to ship these with 1.0, but they're specifically needed by some production users.

    The biggest feature here is the ability to manually specify the ON clause of a join, which is separate from the associations API. You can also use this to join to tables which otherwise have no association between them (but this will also require you to invoke enable_multi_table_joins!).

    In addition to the Diesel core team, 6 people contributed to this release. A huge thank you to:

    • Alex Kitchens
    • Maciej Dziardziel
    • Pyry Kontio
    • Sunrin SHIMURA (keen)
    • king6cong
    • wangcong
    Source code(tar.gz)
    Source code(zip)
  • v0.14.1(Jul 10, 2017)

    This is a bugfix release addressing an issue with sum and avg. These were mistakenly treated as returning the same type as their argument. However, these functions return NULL when run against an empty database, which could result in errors.

    Source code(tar.gz)
    Source code(zip)
  • v0.13.1(Jul 10, 2017)

    This is a bugfix release addressing an issue with sum and avg. These were mistakenly treated as returning the same type as their argument. However, these functions return NULL when run against an empty database, which could result in errors.

    Source code(tar.gz)
    Source code(zip)
  • v0.14.0(Jul 4, 2017)

    One of the oldest issues in Diesel was that we limited the number of tables that could appear in a single query to 2. The problem was never about having more than 2 tables, but safely and correctly proving in the type system what would and could not be selected from that join.

    With 0.14, that restriction has been removed. The query builder now supports joins containing an arbitrary number of tables. You may find that you need to call enable_multi_table_joins! for a few tables, but that need should go away in the future as specialization matures.

    In addition to the headline feature, this release includes support for several new datatypes (including NUMERIC/DECIMAL which has been widely requested), and other small quality of life improvements. As always, you can see the CHANGELOG for the full release notes.

    The Road to 1.0

    A recent point of discussion among the core team has been what remaining blockers we have for releasing a version 1.0. The roadmap doesn't necessarily include everything that would make us "feature complete". It focuses on the set of changes that we think are likely to require breaking changes.

    We expect that this will be the last 0.x release. You can follow the milestone here. Additionally, we all agreed that the biggest blocker to a 1.0 release is improvements to our documentation. We're going to be doing a big push in the coming months to clean things up, and are looking for help from the community. You can follow that project here, or just come join us in our gitter room to talk about how you can help.

    There will be a blog post with more details about this in the coming weeks.

    Contributors

    In addition to the core team, 10 people contributed to this release. A huge thank you to:

    • Dorian Scheidt
    • FliegendeWurst
    • Georg Semmler
    • JD Gonzales
    • Jim McGrath
    • Kieran
    • Ruben De Smet
    • Sunrin SHIMURA (keen)
    • Tshepang Lekhonkhobe
    • theduke

    Core Team Changes

    With this release, we are also making some changes to the core team to better reflect the current active maintainers. In recognition of his fantastic work, we're pleased to welcome @Eijebong to the core team. Many early members of the team have also since moved onto other projects. To reflect that, Mike Piccolo, Matt Casper, and Sam Phippen are all being moved to the core team alumni.

    Source code(tar.gz)
    Source code(zip)
  • v0.13.0(May 15, 2017)

    This release adds support for date and time types with SQLite, allows for raw SQL to use bind parameters, and updates our dependencies (notably allowing serde 1.0).

    As always, you can find the full release notes in the CHANGELOG

    In addition to the core team, 11 people contributed to this release. A huge thank you to:

    • Tobias Schottdorf
    • Dorian Scheidt
    • Danilo Bargen
    • Enether
    • John Gallagher
    • James Kominick
    • pfernie
    • Blake Pettersson
    • Mark Catley
    • Bastien Orivel
    • Sunrin SHIMURA (keen)
    • kardeiz
    Source code(tar.gz)
    Source code(zip)
  • v0.12.0(Mar 16, 2017)

    The main feature of this release is support for PG's ON CONFLICT DO UPDATE, which brings our support for upsert on PG to nearly the entire range of possible syntax. Additionally, this release contains support for some new data types and operators, and several bug fixes.

    Finally, the way that we handle joins has been going through a huge overhaul internally. For the most part this doesn't affect public API yet, but you may notice an increase in compile times, and more things "just working" the way you'd expect when working with joins. This work will hopefully lead to 3+ table joins in the next release.

    As always, you can find the full release notes in the CHANGELOG

    In addition to the core team, 11 people contributed to this release. A huge thank you to:

    • Taryn Hill
    • Eijebong
    • Martijn de Haan
    • Mrmaxmeier
    • Daniel Durante
    • Patrick Fernie
    • Erich Cordoba
    • Sid Ngeth
    • pfernie
    • John Gallagher
    • theduke
    Source code(tar.gz)
    Source code(zip)
Owner
Diesel
Diesel is a Safe, Extensible ORM and Query Builder for Rust
Diesel
Diesel - ORM and Query Builder for Rust

A safe, extensible ORM and Query Builder for Rust API Documentation: latest release – master branch Homepage Diesel gets rid of the boilerplate for da

Diesel 9.7k Jan 6, 2023
A query builder that builds and typechecks queries at compile time

typed-qb: a compile-time typed "query builder" typed-qb is a compile-time, typed, query builder. The goal of this crate is to explore the gap between

ferrouille 3 Jan 22, 2022
Bind the Prisma ORM query engine to any programming language you like ❤️

Prisma Query Engine C API Bind the Prisma ORM query engine to any programming language you like ❤️ Features Rust bindings for the C API Static link li

Prisma ORM for community 10 Dec 15, 2022
Bind the Prisma ORM query engine to any programming language you like ❤️

Prisma Query Engine C API Bind the Prisma ORM query engine to any programming language you like ❤️ Features Rust bindings for the C API Static link li

Odroe 6 Sep 9, 2022
A Rust SQL query builder with a pleasant fluent API closely imitating actual SQL

Scooby An SQL query builder with a pleasant fluent API closely imitating actual SQL. Meant to comfortably build dynamic queries with a little bit of s

Aleksei Voronov 100 Nov 11, 2022
Fully typed SQL query builder for Rust [deprecated]

What is Deuterium? Deuterium is a fancy SQL builder for Rust. It's designed to provide a DSL to easily build SQL queries in safe and typed way. Like R

Stanislav Panferov 169 Nov 20, 2022
Type-safe SQL query wrappers

fnsql   The fnsql crate provides simple type-safe optional wrappers around SQL queries. Instead of calling type-less .query() and .execute(), you call

Dan Aloni 9 Apr 29, 2022
ORM for ScyllaDb and Cassandra

ScyllaDb/Cassandra Object-Relation Mapper Features This library contains several crates with the following features: Automatic map tables to Rust stru

null 36 Jan 1, 2023
CRUD system of book-management with ORM and JWT for educational purposes.

Book management English | 中文 Required Rust MySQL 5.7 Usage Execute init.sql to create tables. Set environment variable DATABASE_URL and JWT_SECRET in

null 32 Dec 28, 2022
an orm for rust

rustorm Rustorm Rustorm is an SQL-centered ORM with focus on ease of use on conversion of database types to their appropriate rust type. Selecting rec

Jovansonlee Cesar 236 Dec 19, 2022
🐚 An async & dynamic ORM for Rust

SeaORM ?? An async & dynamic ORM for Rust SeaORM SeaORM is a relational ORM to help you build web services in Rust with the familiarity of dynamic lan

SeaQL 3.5k Jan 6, 2023
Ormlite - An ORM in Rust for developers that love SQL.

ormlite ormlite is an ORM in Rust for developers that love SQL. It provides the following, while staying close to SQL, both in syntax and performance:

Kurt Wolf 28 Jan 1, 2023
Rust High Performance compile-time ORM(RBSON based)

WebSite | 简体中文 | Showcase | 案例 A highly Performant,Safe,Dynamic SQL(Compile time) ORM framework written in Rust, inspired by Mybatis and MybatisPlus.

rbatis 1.7k Jan 7, 2023
ReefDB is a minimalistic, in-memory and on-disk database management system written in Rust, implementing basic SQL query capabilities and full-text search.

ReefDB ReefDB is a minimalistic, in-memory and on-disk database management system written in Rust, implementing basic SQL query capabilities and full-

Sacha Arbonel 75 Jun 12, 2023
rust_arango enables you to connect with ArangoDB server, access to database, execute AQL query, manage ArangoDB in an easy and intuitive way, both async and plain synchronous code with any HTTP ecosystem you love.

rust_arango enables you to connect with ArangoDB server, access to database, execute AQL query, manage ArangoDB in an easy and intuitive way, both async and plain synchronous code with any HTTP ecosystem you love.

Foretag 3 Mar 24, 2022
Rust library to parse, deparse and normalize SQL queries using the PostgreSQL query parser

This Rust library uses the actual PostgreSQL server source to parse SQL queries and return the internal PostgreSQL parse tree.

pganalyze 37 Dec 18, 2022
Query is a Rust server for your remote SQLite databases and a CLI to manage them.

Query Query is a Rust server for your remote SQLite databases and a CLI to manage them. Table Of Contents Run A Query Server CLI Install Use The Insta

Víctor García 6 Oct 6, 2023
Query LDAP and AD with SQL

SQLDAP Ever wanted to query AD or LDAP with SQL like queries ? I'm going to answer this question myself: yes ! Why ? Because I never could remember al

null 9 Nov 15, 2022
XLite - query Excel (.xlsx, .xls) and Open Document spreadsheets (.ods) as SQLite virtual tables

XLite - query Excel (.xlsx, .xls) and Open Document spreadsheets (.ods) as SQLite virtual tables XLite is a SQLite extension written in Rust. The main

Sergey Khabibullin 1.1k Dec 28, 2022