* Cache insert statments from queries, as those are safe to cache if the
query itself is safe to cache
* Add a way to directly insert from a statically sized array
* Decouple default values from insert expressions and allow to generate
insertable implementations that do not use the default values.
+ This unblocks real batch inserts on sqlite
+ This allows cache the prepared statements for insert from statically sized arrays as we know the size at compile time here
* Update the benchmarks to use the statically compile time variant.
Other implementations also use prepared statements here, so this is
just fair
This commit adds support for generating SQL type definitions for unknown
types to `diesel print-schema`. The basic idea is to generate the
corresponding marker type to always end up with an existing schema.
Especially this does not generate any code that is required for
serializing/deserializing rust values.
This commit changes all connection implementations to take `&mut self`
on all methods that interact with the database.
This unblocks the following features:
* Returnig a cursor/iterator from a `RunQueryDsl` method
* Removing some unsafe code and interior mutability inside the current
connection implementations
* Possibly the first step of a async `Connection` variant to workaround
the `Future` not `Send` issues there.
This fixes the handling of panics in custom SQLite functions
by having a `catch_unwind` before ffi the boundary and by correctly
setting the required `UnwindSafe` trait bounds in a similar way as it is
done by rusqlite.
We enforce now that the order clause matches the corresponding
distinct_on clause. I've choosen to gate setting a distinct on clause on
having a corresponding order clause.
d2af2263c7 had to roll back the impl of `AsExpression<Nullable<sql_types::Bool>>` for `E: AsExpression<sql_types::Bool>`, to allow for more type inference, but forgot to remove the corresponding line in the changelog.
Similar to how `#[diesel(deserialize_as)]` can be used for `Queryable`
structs to customize which type is being constructed, we add support
for doing the same thing for `Insertable` structs.
The conversion happens using the std trait `Into` which takes ownership
during conversion. As such, as soon as any field within an `Insertable`
struct has a `#[diesel(serialize_as)]` attribute, we no longer generate
an implementation of `Insertable` for borrowed versions of this struct.
Fields annotated with `#[diesel(serialize_as)]` are also incompatible
with `#[diesel(embed)]`. Using both on the same field will result in
a compile-error.
- Adds support for PostgreSQL's `SIMILAR TO` and `NOT SIMILAR TO`.
- Adds support for `ESCAPE` to PostgreSQL's `ILIKE`, `NOT ILIKE`, `SIMILAR TO` and `NOT SIMILAR TO`.
- Adds doc tests for all of the above by repurposing existing tests that function the same.
Include parenthesis around every infix operation provided by one of the
`ExpressionMethod` traits.
It is not possible to include this directly into the `infix_operator!`
macro due several SQL constructs:
* `a LIKE b` can have optional `ESCAPE` clauses (same for `NOT LIKE`,
`ILIKE` eg). Unconditionally putting a parenthesis around `(a LIKE b)`
is no valid SQL
* `a BETWEEN l AND u` is implemented a set of two infix operators,
`BETWEEN` and `AND`, so putting the parenthesis directly into the
operator macro would lead to `x BETWEEN (l AND u)` which is not valid
SQL
Instead I've opted for adding explicit parenthesis in the corresponding
`ExpressionMethod` (and similar traits` implementations. As part of this
change I've changed all the return types there to use some type from
`diesel::dsl`, so that potential users have an easier time to figure out
what types to use if they have to write some where clause or something
like that.
While changing the return types to `diesel::dsl` types I noticed and
fixed the following issues:
* Not all methods had an equivalent type in `diesel::dsl`, sometimes
because it was missing, sometimes because the postgres specific types
weren't correctly exported there. Both is fixed now
* Some types were not anymore compatible with the actual methods. A
notable example is `dsl::And` and `BoolExpressionMethods::and` where the
later returned a potentially nullable type depending on the input types,
while the first was only valid for not nullable right sides. Fixing that
was a bit more complicated:
* I've opted for making the return type of `BoolExpressionMethods::and`
(and `or`) unconditonally nullable. This prevents having an explicit
`ST` parameter on `dsl::And`
* This in turn requires that we accept a non nullable expression in
places where a nullable expression is expected. Technically this
was already possible, but would require explicitly calling
`.nullable()` on affected expressions. Given that `.and()` and
`.or()` are really common, that seemed not to be a good solution.
As result I've changed the `AsExpression` impl for `T: Expression`
in such a way that for any `T` with `T::SqlType: SqlType<IsNull =
is_nullable::NotNull>` there is now an impl
`AsExpression<Nullable<T::SqlType>>` so that such expressions are
also accepted in nullable contexts.
This makes the minor changes to `sql_function!` required to allow 0
argument functions to be defined with this macro. `no_arg_sql_function!`
has been deprecated. Even though we could technically remove it since
this is a major version bump, I still would prefer to deprecate things
when possible, so `no_arg_sql_function!` will live on until 3.0.
There are some changes in behavior here. The most notable is that we
generate a function rather than a unit struct. I had previously
considered having the macro create a unit struct instead of a module if
there were no arguments, but ultimately I think the difference in
behavior is confusing, and requiring folks to put `()` at the end of
calls isn't a huge migration pain.
The biggest thing that `sql_function!` doesn't support is the ability to
add a constraint to the backends allowed. This capability was originally
added for `NOW()`, back when we actually generated that SQL instead of
`CURRENT_TIMESTAMP`. We stopped using it a long time ago, and I doubt
anyone else is using this in the wild. Honestly it was a pretty poorly
thought out feature to begin with, so I'm happy to see it go. If we
decide in the future we want to support this for `sql_function!`, I
think the best way to do it is to allow `where` clauses at the end, and
any bounds that are on `DB` get magically applied to the write
impls/type variable. That behavior feels really implicit and confusing,
so I think we should probably just encourage folks to not use
`sql_function!` if they need lower level control.
One unfortunate side effect of this is that `now` still doesn't get
parenthesis, and we can't have a function and struct with the same name.
If we *really* want to migrate `now` to be consistent, we could
implement all the traits implemented on `now` for `fn() -> now`. This is
a terrible terrible awful hack but could actually work.
(Sorry for the really large diff but this touches nearly all parts of
diesel)
This commit does in two things:
* Refactor our handling of nullable values. Instead of having a marker
trait for non nullable sql types we now indicate if a sql type is
nullable by using a associated type on a new fundamental trait named
SqlType. This allows us to reason if an type is nullable or not in a
much precise way without running in conflicting implementation
issues. This allows us to address #104 in a much more fundamental
way. (The correct way as mentioned there by sgrif).
* Refactor our handling of typed and untyped sql fragments. Instead of
having two separate code paths for `Queryable` (sql types known) and
`QueryableByName` (sql types not known) we now have only one code path
and indicate if a query is typed or untyped as part of the expression
sql type. This is required to address #2150. `Queryable` and
`QueryableByName` now simple . Additionally we separate the static size component of
`FromSqlRow` to allow dynamically sized rows there (but only at the
last position for tuple impls.)
I should probably have implement those changes in different commits
but as both changes basically requiring touching most of our code base
this would have required much more work...
Both changes are theoretically big major breaking changes. For
application code I expect the actual breakage to be minimal, see the
required changes in `diesel_tests` and `diesel_cli` for examples. For
highly generic code I would expect quite a few required changes.
Additionally there are a few small drive by fixes.
Fixes#104Fixes#2274Fixes#2161
* Lower all dependencies to `-Z minimal-versions` in CI
* Raise the following public dependencies:
* bigdecimal to 0.0.13 to drop support for old num versions
* chrono to 0.4.1 because it pulls in a really old num from before
the rust 1.0 release
* pq-sys to 0.4.0 because 0.3.x pulls in a old bindgen version
* mysqlclient-sys to 0.3.0 for the same reason
* Bump this internal dependencies:
* syn to 1.0.1 because we require at least that version
* num-* to 0.2.0 to match bigdecimal version
* bcrypt to 0.2.0 because it would pull in rustc-serialize
otherwise
* tempfile to 3.0.0 because otherwise it pulls in winapi 0.0.1!!!
* bitflags to 1.2.0 because of deprecation warnings regarding to try!
