Diesel 2.0 update thread.

[weiznich]

This thread is dedicated to feedback about updating existing code bases to diesel 2.0.

We are interesting in the following information:

• Which crate did you update? (Possibly with link to the corresponding code base)
• Did you hit any show stoppers?
• Did you find any important information were missing from the migration guide?
• Did you notice other problems?

Useful Resources:

• Changelog
• Migration Guide Draft
• API Documentation

[Heliozoa]

Nice work!

I upgraded a (currently private) hobby project of mine and it went smoothly with just a couple of find and replaces except that the new version didn't like me having a column in my database named alias:

error[E0308]: mismatched types
   --> src/schema.rs:248:1
    |
248 | / table! {
249 | |     tag_aliases (id) {
250 | |         id -> Int4,
251 | |         created -> Timestamptz,
...   |
257 | |     }
258 | | }
    | | ^
    | | |
    | | expected struct `Alias`, found struct `tag_aliases::columns::alias`
    | | expected due to this
    | | unit struct defined here
    | |_`alias` is interpreted as a unit struct, not a new binding
    |   help: introduce a new binding instead: `other_alias`
    |
    = note: expected struct `Alias<S>`
               found struct `tag_aliases::columns::alias`
    = note: this error originates in the macro `$crate::__diesel_table_impl` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0599]: no method named `field` found for struct `tag_aliases::columns::alias` in the current scope
   --> src/schema.rs:248:1
    |
248 | / table! {
249 | |     tag_aliases (id) {
250 | |         id -> Int4,
251 | |         created -> Timestamptz,
...   |
257 | |     }
258 | | }
    | | ^
    | | |
    | |_method `field` not found for this
    |   method not found in `tag_aliases::columns::alias`
    |
    = note: this error originates in the macro `$crate::__diesel_table_impl` (in Nightly builds, run with -Z macro-backtrace for more info)

Some errors have detailed explanations: E0308, E0599.
For more information about an error, try `rustc --explain E0308`.

The error didn't make too much sense to me at first, but I saw aliasing mentioned in the release notes so I tried renaming the column which fixed the issue.

I tried using Selectable with the derive, naively trying to use column_name to select from other tables

#[derive(Selectable)]
#[diesel(table_name = crate::schema::posts)]
pub struct PostSmall {
    pub id: i32,
    #[diesel(column_name = "thumbnail_filename")]
    pub thumbnail: String,
    pub title: String,
    #[diesel(column_name = "users::id")]
    pub user_id: i32,
    #[diesel(column_name = "users::display_name")]
    pub username: String,
}

but the derive didn't like it. For what it's worth my intent was to replace a macro I wrote that looks like this

make_query! {
    pub struct PostSmall {
        pub id: i32 = posts::id,
        pub thumbnail: String = posts::thumbnail_filename,
        pub title: String = posts::title,
        pub user_id: i32 = users::id,
        pub username: String = users::display_name,
    }
}

I'm happy with my current setup and I even rewrote my macro to create the Selectable impl so it's not a huge deal if the derive is not intended for this kind of usage, this just happened to be the first thing I tried after I got the project to compile with 2.0.

[weiznich]

Thanks for the feedback 👍

Can you provide the unmodified version of the table! macro call that caused the first error? This should not happen and we should likely fix that before a final 2.0 release.

About using Selectable with mixed tables as well: Yes that's a limitation of the current implementation of the derive. I would be open for improvements there. Something like #[diesel(table_name = foo, column_name = bar)] would be likely a good solution to pass the relevant information to the derive.

[Heliozoa]

Sure thing

table! {
    tag_aliases (id) {
        id -> Int4,
        created -> Timestamptz,
        tag_id -> Int4,
        alias -> Text,
        language -> Nullable<Text>,
        main -> Bool,
        canonical -> Bool,
    }
}

[weiznich]

Thanks for the table! definition. I've filled #3146 to fix the underlying problem.

[omid]

Thanks @weiznich and the team for the awesome work.

I've faced these issues, till now.

1. It's not so clear what should we use instead of not_none macro.
2. Here it said use RawValue<DB>, but I think it should be RawValue<'_, DB>. Maybe we can mention that it's possible to use other types, like PgValue and ...
3. I faced the error that "transaction_manager" method is not there in PgConnection. I think we should use AnsiTransactionManager directly. Not mentioned anywhere in the migration doc.
4. There are several warnings like warning: #[sql_type] attribute form is deprecated, but it's not clear at which file:line they happen.
5. I enabled uuid feature, but I still see errors like the trait 'diesel::Expression' is not implemented for 'uuid::Uuid' and so on.
   I think the reason is that we use different versions of uuid!
   Just add these deps to a sample project, then run cargo tree -i uuid:

diesel = {version = "2.0.0-rc.0", features = ["uuid"]}
uuid = "=0.8.2"

I have the latest stable Rust version.

[weiznich]

Thanks for the feedback

It's not so clear what should we use instead of not_none macro.

It is not required anymore. The signature of FromSql::from_sql changed so that it does not accept an Option anymore. Probably we should state that as part of the migration guide?

Here it said use RawValue, but I think it should be RawValue<'_, DB>. Maybe we can mention that it's possible to use other types, like PgValue and ...

Lifetime elision should make it possible to remove that lifetime. Nevertheless we could add that to the migration guide.

I faced the error that "transaction_manager" method is not there in PgConnection. I think we should use AnsiTransactionManager directly. Not mentioned anywhere in the migration doc.

That's because Connection::transaction_manager was never part of the public API. So this is covered with this point of the migration guide. You can likely replace that by using a concrete connection manager implementation directly.

There are several warnings like warning: #[sql_type] attribute form is deprecated, but it's not clear at which file:line they happen.

This is unfortunately not possible as rustc does not offer a API for this as part of the stable proc macro api.

I enabled uuid feature, but I still see errors like the trait 'diesel::Expression' is not implemented for 'uuid::Uuid' and so on.
I think the reason is that we use different versions of uuid!
Just add these deps to a sample project, then run cargo tree -i uuid:

This sounds more like an issue with cargo's resolver algorithm, than an issue with diesel. Diesel specifies that it supports any uuid version between ">=0.7, <2.0". Cargo somehow seems to believe that it must chose "1.0" in this case, even if the other crate depends on some other version that is supported by diesel as well. That written: I do not see any improvement here, without removing support for at uuid 0.7 and 0.8.

[omid]

Thanks.

I solved all issues, except the last one. And mentioned my struggles here, which may worth mentioning in the migration doc.

That's because Connection::transaction_manager was never part of the public API. So this is covered with this point of the migration guide. You can likely replace that by using a concrete connection manager implementation directly.

I have an async function to run an async Fn in a transaction. And there, I used the Connection::transaction_manager.

This sounds more like an issue with cargo's resolver algorithm, than an issue with diesel. Diesel specifies that it supports any uuid version between ">=0.7, <2.0". Cargo somehow seems to believe that it must chose "1.0" in this case, even if the other crate depends on some other version that is supported by diesel as well. That written: I do not see any improvement here, without removing support for at uuid 0.7 and 0.8.

I agree with that it is related to cargo and not diesel. But we are in this ecosystem. I'm trying to find the issue exactly. To see if it is rust edition, cargo resolver or a hidden flag somewhere or …!
Anyway… another solution can be to again have some features like before, “uuid-0_8” and “uuid-1” 🙈 (like tokio-postgres)

So shortly my suggestion is that to have:

• Removal of need check not_none macro
• Have PgValue and other family members in the doc (with or without the lifetime)

[weiznich]

To see if it is rust edition, cargo resolver or a hidden flag somewhere or …!

As far as I'm aware there is currently no way to influence this behaviour. At least other than manually setting the "right" version via cargo update -p uuid --precise=0.8.0.

Anyway… another solution can be to again have some features like before, “uuid-0_8” and “uuid-1” 🙈 (like tokio-postgres)

To be clear here, there are exactly the following "solution" to this problem:

• Use distinct feature flags for different versions, which is bad because it leads to code duplication (each feature requires it's own duplication) and a unbounded number of feature flags which cannot be tested on CI
• Support a compatible version range, which is bad because of the reasons explained above
• Drop support for old versions, which is bad because it drops support for otherwise compatible code
• Do not support external types at all, which is bad because no support for anything else than std at all.

So yes, there is just no good solution to this problem. We need to accept that it sometimes just not work.

Have PgValue and other family members in the doc (with or without the lifetime)

That's about the migration guide? Or the API documentation?

[omid]

As far as I'm aware there is currently no way to influence this behaviour. At least other than manually setting the "right" version via cargo update -p uuid --precise=0.8.0.

Yes, I could do so with this command: cargo update -p uuid:1.0.0 --precise=0.8.2
Anyway, we are discussing this here: rust-lang/cargo#10599

That's about the migration guide? Or the API documentation?

Migration guide

[Justice4Joffrey]

Thanks @weiznich - the new features are pretty much exactly what I was looking for from using 1.4.

I've migrated a bunch of stuff and haven't faced any problems so far.

The only thing which was an inconvenience was not being able to use a generic connection with the SaveChangesDSL. Wanted to get your views on that - example here.

[weiznich]

The only thing which was an inconvenience was not being able to use a generic connection with the SaveChangesDSL. Wanted to get your views on that - example here.

I just checked that: It does not work with diesel 1.4 either, so that's not "related" to the release. Anyway, that might be caused by a missing trait implementation for the PooledConnection connection wrapper type. I would accept a PR fixing that.

(As another note: You don't need to define your own PostgresConnection trait there, you could just use impl Connection<Backend = Pg> instead.)

[Justice4Joffrey]

I did consider that, but found it a bit awkward to read/write.

Weird - afaik this was working before I migrated 🤕...

I'll have a stab at a PR.

[Justice4Joffrey]

Looks awkward. Moved to #3158

[htunlogic]

We have a project we are working on and we started it off with Diesel 1.4, but since it's still in development we jumped on the chance to test it and continue the work on 2.0 version.

Most of the stuff is already migrated, but now I am facing a blocker to move forward (maybe there is a simple solution).

Basically, we have some query builders internally and we used the BoxedSelectStatement to do that, we would define the type like this:

type DieselBoxedType<'a> = diesel::query_builder::BoxedSelectStatement<
    'a,
    user_sessions::SqlType,
    user_sessions::table,
    diesel::pg::Pg,
>;

But, BoxedSelectStatement is no longer publicly available from outside the Diesel crate.

but even if it was, I still get an error that seems like this won't be possible to do anymore, this is some example code:

impl ExamplePgRepository {
    pub fn start_query<'a>(&self) -> DieselBoxedType<'a> {
        user_sessions::table.into_boxed()
    }
}

The error I get:

mismatched types
expected struct `BoxedSelectStatement<'a, _, infrastructure::schema::user_sessions::table, _, _>`
   found struct `BoxedSelectStatement<'_, _, FromClause<infrastructure::schema::user_sessions::table>, _, _>`

As I can see, the error could easily be solved with FromClause which is also not available unless I turn on the i-implement-a-third-party-backend-and-opt-into-breaking-changes feature. But that still doesn't solve the issue with BoxedSelectStatement which is not covered by that feature flag.

Is this a bug or is it on purpose so I should do it differently?

[weiznich]

So the main problem with that is that BoxedSelectStatement was never part of the public API (read that as it never appeared in the official API documentation). The upcoming 2.0 just makes that a hard error.

After having that written: You likely want to use the BoxedQuery type defined by the table! macro instead.

[htunlogic]

Oh my, can't believe I missed that, thats even simpler then whatever we were doing before! Thank you very much :)

[mcncm]

Thanks to everyone who contributed to this milestone; it's an impressive piece of work!

One point of friction I've had is with types like

#[derive(Queryable)]
struct MyTaggedStruct {
   // ... other fields ...
   tags: Vec<String>,
}

In the 1.4 releases, this struct would map to a SQL column of type TEXT[] NOT NULL. In this release it does not. Now, that's is probably the technically "right" choice, since the elements of such a SQL array are in fact nullable. But what should we do now, in the case of MyTaggedStruct? Something like #[diesel(deserialize_as = "MyNonNullableVec")] with a custom Queryable implementation? Apologies if I've missed something important in the documentation!

[weiznich]

The right format for this would be a new idea discussion thread outlining a potential API. Thats would be a great way to start discussing a new feature that should be added to diesel.

[marcusbuffett]

Just want to chime in that I tried to switch to 2.0 earlier today and found this quite cumbersome. Option 1 of using Vec<Option> didn't really match up with how I'm using these columns, since in practice they won't have nulls, so having to go through my code and account for all these nulls felt like needless complexity. Option 3 of using deserialize_as felt kind of hand-wavey, I tried #[diesel(deserialize_as = Vec<String>)], but couldn't figure out how to make it work. I went with the patch_file option but it feels really hacky, for something that was zero hassle in 1.x .

[marcusbuffett]

Actually even with changing the schema.rs columns back to Array<Text>, I get Message: called Result::unwrap() on an "Err" value: DatabaseError(Unknown, "could not find array type for data type text[]") when trying to load the model.

[marcusbuffett]

To give a bit more info on the above, here's the schema:

diesel::table! {
    use diesel::sql_types::*;
    use crate::enums::*;

    opening_lines (line) {
        line -> Array<Text>,
        white_incidence -> Float8,
        black_incidence -> Float8,
        previous_line -> Nullable<Array<Text>>,
        depth -> Int4,
        games -> Int4,
        id -> Text,
    }
}

In the above schema I've replaced both Array<Nullable<Text>>s with Array<Text>.

And the query looks like this:

schema::opening_lines::table
        .filter(schema::opening_lines::dsl::previous_line.eq_any(my_lines.clone()))
        .load(conn)
        .unwrap();

This was working with 1.4

[weiznich]

Thanks for reporting back. As already stated above multiple times: This change is expected and we will not revert it. I'm happy to receive concrete suggestions how the migration guide or the general handling can be improved.
To address specific points:

Option 3 of using deserialize_as felt kind of hand-wavey, I tried #[diesel(deserialize_as = Vec)], but couldn't figure out how to make it work.

Please checkout the linked documentation. You need to provide your own wrapping type there + implement a custom conversion as shown in the example. Vec<String> does not meet these criteria.

Actually even with changing the schema.rs columns back to Array, I get Message: called Result::unwrap() on an "Err" value: DatabaseError(Unknown, "could not find array type for data type text[]") when trying to load the model.

I can reproduce this error, but it is not related to the array nullable change. We optimized internally the sql that is generated for .eq_any() a = ANY($1) expression instead of IN($1, … $n) as this is much more efficient. Unfortunately for your example this would require support for multi-dimensional arrays, which is something that is not implemented yet. You can generate the same error message on 1.4.x by changing your filter to previous_line.eq(diesel::dsl::any(my_lines)). Now there is unfortunately no easy fix for this problem as we would need to determine the correct OID (for nested array?) for such an bind before creating it and that's something I cannot find documentation on.
That written: I would appropriate a bug report filled at our issue tracker, so that this does not get lost here. For anyone interested in looking into this: I believe the problem is this HasSqlType impl:

diesel/diesel/src/pg/types/array.rs

Lines 12 to 22 in df7ca0a

	impl<T> HasSqlType<Array<T>> for Pg
	where
	Pg: HasSqlType<T>,
	{
	fn metadata(lookup: &mut Self::MetadataLookup) -> PgTypeMetadata {
	match <Pg as HasSqlType<T>>::metadata(lookup).0 {
	Ok(tpe) => PgTypeMetadata::new(tpe.array_oid, 0),
	c @ Err(_) => PgTypeMetadata(c),
	}
	}
	}

I think we need to handle cases where array_oid == 0 in a special way there, as those are the cases for nested arrays, but I haven't found a solution yet.

[heyrict]

Thank you for all your efforts for bringing this big release! I have successfully migrated my hobby project to use diesel 2.0.0-rc.0 without much trouble, the full code changes are here. Here are some minor problems that I encountered:

1. table.distinct_on(col).order(col.desc()) will not compile in diesel 2. This have been reported in Unable to sort columns used in a DISTINCT ON #3020 . I've replaced that with a custom sql as a workaround.
2. For dynamic queries, it seems that DB should be a concrete type rather than a generic impl Backend

-pub trait CindyFilter<Table: Send, DB> {
-    fn as_expression(self) -> Option<Box<dyn BoxableExpression<Table, DB, SqlType = Bool> + Send>>;
+pub trait CindyFilter<Table> {
+    fn as_expression(self) -> Option<Box<dyn BoxableExpression<Table, diesel::pg::Pg, SqlType = Bool>>>;
 }

3. The assumed_not_nullable function noted in migration guide is miss-spelled. It is assume_not_null.
4. I have encountered the issue that temporary values cannot be created in ToSql implementation. Changing to a concrete DB type solves that.

[heyrict]

Thank you for your clarification! Glad to find that benchmark already exists for diesel.
After brief testing, it seems aggregations consumes much more time compared with diesel 1.4 when using r2d2::Pool.

Edit: I've opened an issue in #3156 with reproducible example attached. Thank you!

[weiznich]

I've opened #3159 to address the performance regression.

About the error message: You can solve that by adding a bound based on one of the required because of lines listed in the error messages. So something like where diesel::dsl::And<…>: BoxableExpression<…> should solve the issue.

[heyrict]

Thank you for looking into this 👍

For the error message, as the implementation for creating a BoxableExpression is generic, I would rather stick to an exact DB type or make a feature gate for each if I would like to support others, than creating every suggested trait bound for every table. That is barely possible for existing projects.

It seems that most of these implementations are implemented with DB: Backend + DieselReserveSpecialization. What do you think about exposing DieselReserveSpecialization to public, or at least adding relevant information to the migration guide?

[weiznich]

It seems that most of these implementations are implemented with DB: Backend + DieselReserveSpecialization. What do you think about exposing DieselReserveSpecialization to public, or at least adding relevant information to the migration guide?

DieselReserveSpecialization explicitly exists to allow diesel to change some wild card QueryFragment<DB> impls in the future without doing a breaking change. As of such it would not be meaningful to expose this trait as part of the stable API, because then changing such an impl would be a breaking change again. See the corresponding documentation for more details. (It's exposed there behind an explicit i-implement-a-third-party-backend-and-opt-into-breaking-changes feature flag, which hopefully makes it clear that using that trait can and will result in broken code in the future.)
The migration guide already contains a section on covering this point

To be clear here: This is a deliberate change, that hopefully allows us as diesel developers to tweak the query AST implementation in the future without requiring regular breaking changes. Additionally this mainly "just" hides parts of the already not stable API.

[heyrict]

Well, I should have noticed the changes to generics section rather then sticking to the BoxableExpression one. Any way, thanks for the clarification! Looking forward to see the major release then 👍

[vcombey]

https://github.com/adwhit/diesel-derive-enum doesn't work anymore,
see the issue: adwhit/diesel-derive-enum#7
Maybe there is something that replaces diesel-derive-enum in diesel 2.0?

[weiznich]

I assume you wanted to link adwhit/diesel-derive-enum#73?
Anyway that looks like an issue with diesel-derive-enum and as such it should be fixed there.
Generally speaking: We do not plan to add any new functionality to the 2.0 release compared to the rc release. Additionally we are also not interested to add the diesel-derive-enum functionality to diesel itself in one of the next releases, because that's a significant feature and we are already lacking on maintainer capacity. That means anything significant that could be done by a third party crate should be done by a third party crate.

[Justice4Joffrey]

Migrating code using diesel-derive-enum to diesel 2.0 is a bit involved, but it is documented on the home page of that project.

In short, you no longer use #[DieselType] and #[PgType] and the library now defines shadow copies of your custom enum types in schema::sql_types.

[Ten0]

Given the error it looks like the issue just comes from using Diesel CLI 1.4 with Diesel 2 (adwhit/diesel-derive-enum#73 (comment))

[Siceberg]

I am using both diesel 2.0 and oso in a project, if I define a struct:

#[derive(PolarClass)]
#[diesel(table_name = accounts)]
pub struct Account {
    #[polar(attribute)]
    pub id: Uuid,
    pub email: String,
}

get error:

proc-macro derive panicked
message: called `Result::unwrap()` on an `Err` value: Error("expected literal")

if use #[table_name = "accounts"], will not have the above problem.

[weiznich]

Thanks for this report. Can you provide an minimal example without using a third party crates? Otherwise this seems for me like an issue with the other crate, as no diesel derive is directly involved here.

[Siceberg]

Here is demo: https://github.com/Siceberg/oso-diesel2-conflict-demo

[weiznich]

Thanks for coming back with an minimal example.
As this error is caused by a panic in oso::PolarClass and that's not diesel code I cannot see how this would be an diesel issue. For me this just looks like a broken implementation of the oso::PolarClass derive macro. Please fill an issue in their repository as this is not a diesel bug. It might be caused by this unwrap

Otherwise: Please note that #[derive(Queryable)] does not need or even support #[diesel(table_name = …)]. Checkout this documentation for a list of supported attributes.

[Siceberg]

Thank you very much, your reply brought my attention to the details I left out.

[rj76]

Hello, thanks for this project!

I'm migrating to release 2.0.0 and I'm running into a problem (which is not necessarily diesel related, I realize that) with pagination which is based on the advanced blog example. I refactored to use &mut connections, and changed lifetimes and everything looks good except for an error:

error[E0277]: the trait bound `(<T as diesel::query_builder::Query>::SqlType, BigInt): load_dsl::private::CompatibleType<(U, i64), Pg>` is not satisfied
  --> src/pagination.rs:87:23
   |
87 |                 query.load_and_count_pages::<U>(conn)?
   |                       ^^^^^^^^^^^^^^^^^^^^ the trait `load_dsl::private::CompatibleType<(U, i64), Pg>` is not implemented for `(<T as diesel::query_builder::Query>::SqlType, BigInt)`
   |
   = note: required because of the requirements on the impl of `LoadQuery<'_, diesel::PgConnection, (U, i64)>` for `Paginated<T>`
note: required by a bound in `Paginated::<T>::load_and_count_pages`
  --> src/pagination.rs:59:19
   |
57 |     pub fn load_and_count_pages<'a, U>(self, conn: &mut PgConnection) -> QueryResult<(Vec<U>, i64, i64)>
   |            -------------------- required by a bound in this
58 |         where
59 |             Self: LoadQuery<'a, PgConnection, (U, i64)>,
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ required by this bound in `Paginated::<T>::load_and_count_pages`
help: consider extending the `where` bound, but there might be an alternative better way to express this requirement
   |
77 |         U: Queryable<Self::SqlType, Pg>, (<T as diesel::query_builder::Query>::SqlType, BigInt): load_dsl::private::CompatibleType<(U, i64), Pg>

The errors occur here https://gist.github.com/rj76/3a0f2635473a54e3f880cd14ea46e84e#file-pagination-rs-L88

I tried modifying the where of impl LoadPaginated on line 78, but it's referencing a private field.

Do you have any directions as to what to change to fix the error? Is the change of the lifetimes causing this?

[weiznich]

Have a look at this example: https://github.com/diesel-rs/diesel/blob/e23c38225bad79ad2811c11cfea653375306d5ad/examples/postgres/advanced-blog-cli/src/pagination.rs

[rj76]

Thank you. All works perfectly now.

[nyvs]

I am just wondering if it's just me, but since the update to 2.0.0-rc.0 rust analyzer doesn't like the scheme file anymore even though everything works just fine. It is somewhat inconvenient. Do I miss something here?

[weiznich]

Please report that to the rust-analyzer team. They are always interested in learning about cases where things do not work.
Otherwise: This is not high priority for the diesel team to fix. We would be interested in merging a PR fixing this issue. Otherwise I think a good starting point would be to provide at least a minimal reproducible example, so that we have something to investigate here.

[Ten0]

I do not have this issue, although sometime it takes some time to initialize.

[victorhqc]

Hello 👋

I'm having trouble migrating some BoxedQuery methods.

I have a table like following

table! {
    transactions (id) {
        id -> Text,
        amount -> Integer,
        description -> Nullable<Text>,
        registered_on -> Timestamp,
        created_at -> Timestamp,
        updated_at -> Timestamp,
        deleted -> Bool,
    }
}

// And the model

#[derive(
    PartialEq, Debug, Clone, Insertable, Identifiable, Serialize, Deserialize, Queryable, Selectable,
)]
#[table_name = "transactions"]
pub struct Transaction {
    pub id: Uuid,
    pub amount: i32,
    pub description: Option<String>,
    #[serde(with = "ts_seconds")]
    pub registered_on: NaiveDateTime,
    #[serde(with = "ts_seconds")]
    pub created_at: NaiveDateTime,
    #[serde(with = "ts_seconds")]
    pub updated_at: NaiveDateTime,
    pub deleted: bool,
}

And I have some custom methods to help me reuse some queries that were working fine on 1.4

impl Transaction {
  pub fn in_span<'a, T>(from: T, to: T) -> BoxedQuery<'a>
    where
        T: 'a,
        T: AsExpression<Timestamp>,
        T::Expression: BoxableExpression<transactions::table, Sqlite>,
    {
        transactions::table
            .filter(transactions::registered_on.ge(from))
            .filter(transactions::registered_on.lt(to))
            .into_boxed()
    }
}

type SqlType = <AllColumns as Expression>::SqlType;
type BoxedQuery<'a> = transactions::BoxedQuery<'a, Sqlite, SqlType>;

type AllColumns = (
    transactions::id,
    transactions::amount,
    transactions::description,
    transactions::registered_on,
    transactions::created_at,
    transactions::updated_at,
    transactions::deleted,
);

const ALL_COLUMNS: AllColumns = (
    transactions::id,
    transactions::amount,
    transactions::description,
    transactions::registered_on,
    transactions::created_at,
    transactions::updated_at,
    transactions::deleted,
);

But I'm getting errors when trying to use either ge() or lt()

.filter(transactions::registered_on.ge(from))
   |              ^^^^^^ the trait `ValidGrouping<()>` is not implemented for `<T as AsExpression<diesel::sql_types::Timestamp>>::Expression`
   |
   = note: required for `expression::operators::GtEq<schema::transactions::columns::registered_on, <T as AsExpression<diesel::sql_types::Timestamp>>::Expression>` to implement `ValidGrouping<()>`
   = note: required for `expression::grouped::Grouped<expression::operators::GtEq<schema::transactions::columns::registered_on, <T as AsExpression<diesel::sql_types::Timestamp>>::Expression>>` to implement `NonAggregate`
   = note: required for `SelectStatement<FromClause<schema::transactions::table>>` to implement `FilterDsl<expression::grouped::Grouped<expression::operators::GtEq<schema::transactions::columns::registered_on, <T as AsExpression<diesel::sql_types::Timestamp>>::Expression>>>`
help: consider further restricting the associated type
   |
39 |         T::Expression: BoxableExpression<transactions::table, Sqlite>, <T as AsExpression<diesel::sql_types::Timestamp>>::Expression: ValidGrouping<()>

I've tried limiting the types, like

    where
        GB: IsContainedInGroupBy<
            transactions::registered_on,
            Output = diesel::expression::is_contained_in_group_by::Yes,
        >,
        T: 'a,
        T: AsExpression<Timestamp>,
        T::Expression: BoxableExpression<transactions::table, Sqlite>,
        T: ValidGrouping<()>,
        T::Expression:
            BoxableExpression<transactions::table, Sqlite, SqlType = Timestamp> + ValidGrouping<()>,

// And with this form as well.

where
        GB: IsContainedInGroupBy<
            transactions::registered_on,
            Output = diesel::expression::is_contained_in_group_by::Yes,
        >,
        T: 'a,
        T: AsExpression<Timestamp>,
        T::Expression: BoxableExpression<transactions::table, Sqlite>,
        T::Expression: BoxableExpression<
                transactions::table,
                Sqlite,
                GB,
                <transactions::registered_on as ValidGrouping<GB>>::IsAggregate,
                SqlType = Timestamp,
            > + ValidGrouping<GB>,

But it still keeps failing 😢 some help is highly appreciated, because I'm not sure what I'm doing tbh, I couldn't find an example anywhere

[victorhqc]

Update:

Turns out I can just tell the function to use NaiveDateTime instead of a generic expression and it works

pub fn in_span<'a>(from: NaiveDateTime, to: NaiveDateTime) -> BoxedQuery<'a> {
        transactions::table
            .filter(transactions::registered_on.ge(from))
            .filter(transactions::registered_on.lt(to))
            .into_boxed()
    }

[weiznich]

For reference: The following generic version works as well:

impl Transaction {
  pub fn in_span<'a, T>(from: T, to: T) -> BoxedQuery<'a>
    where
        T: 'a,
        T: AsExpression<Timestamp>,
        T::Expression: BoxableExpression<transactions::table, Sqlite> + ValidGrouping<()>,
        is_aggregate::No: MixedAggregates<<T::Expression as ValidGrouping<()>>::IsAggregate, Output = is_aggregate::No>
    {
        transactions::table
            .filter(transactions::registered_on.ge(from))
            .filter(transactions::registered_on.lt(to))
            .into_boxed()
    }
}

These additional trait bounds specify that the expression does not appear in an aggregate context (group by).

[victorhqc]

It works! Wow, thank you 😍 I just couldn't make it work, makes so much sense after I see how it was supposed to be.

[forest1102]

After Diesel 2.0, since to_sql now requires additional reference parameters, I can't use Jsonb type.
When trying to run the code below, because of the lifetime difference between output in parameters and value in local variables, this code doesn't compile.

use diesel::{
    deserialize::{FromSql, FromSqlRow},
    pg::{Pg, PgValue},
    serialize::{Output, ToSql},
    sql_types::Jsonb,
    AsExpression,
};
use serde::{Deserialize, Serialize};

#[derive(Eq, PartialEq, Debug, Clone, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
#[serde(tag = "type", content = "content")]
pub enum SerializableEnum {
    Messages(Vec<String>),
    Value(String),
    None,
}
#[derive(FromSqlRow, AsExpression, Deserialize, Serialize, Debug, Clone)]
#[serde(rename_all = "camelCase")]
#[diesel(sql_type = Jsonb)]
pub struct SerializableStruct(pub SerializableEnum);

impl FromSql<Jsonb, Pg> for SerializableStruct {
    fn from_sql(bytes: PgValue<'_>) -> diesel::deserialize::Result<Self> {
        let value = <serde_json::Value as FromSql<Jsonb, Pg>>::from_sql(bytes)?;
        Ok(serde_json::from_value(value)?)
    }
}

impl ToSql<Jsonb, Pg> for SerializableStruct
where
    serde_json::Value: ToSql<Jsonb, Pg>,
{
    fn to_sql<'b>(&'b self, out: &mut Output<'b, '_, Pg>) -> diesel::serialize::Result {
        let value = serde_json::to_value(self)?;
        let res = <serde_json::Value as ToSql<Jsonb, Pg>>::to_sql(&value, out);
        res
    }
}

fn main() {
    println!("Hello, world!");
}

[weiznich]

This is covered in the migration guide

[forest1102]

Thanks for telling me.

[apikic]

Hi all,

Great work on new release, people. I have a question about allow_tables_to_appear_in_same_query, did something change about it? Currently I have a workspace project and several packages inside using different db schemas. I used macro allow_tables_to_appear_in_same_query for joining tables in different schemas in different packages. When I used this macro with 1.4.8 version, everything worked well. Now with 2.0.2 I get compiler errors:

impl doesn't use only types from inside the current crate
   'xy::table' is not defined in the current crate
   `Only` is not defined in the current crate

Should all the tables participating in allow_tables_to_appear_in_same_query must be in the same package?
Thanks & Regards

[weiznich]

That sounds like the integration of diesel::alias! required such a change. This implies that we will not revert that change, so it's required for all tables to be in the same crate.

[neysofu]

Hi all,
Thank you for the great work on Diesel. My team uses it a lot internally and we're very happy with it.
I'm having some issues with a multi-column .distinct_on((col1, col2)). The type bounds for DistinctOnDsl now require T: SingleValue which is not implemented for Rust tuples, and I was wondering how one might migrate such a method call over to Diesel 2.

[omid]

I think it's not a good place to ask these questions.
Better ask them in the gitter.

Anyway, I do so:
.distinct_on(dsl::sql::<Bool>("col1, col2"))

[neysofu]

Thank you for the help 😄 I thought this thread would be the right place, as it's asking for feedback and community engagement from people facing issues upgrading to Diesel 2.0. My bad!

[weiznich]

To clarify that: Its totally fine to use this discussion to ask questions about the update to diesel 2.0.
Otherwise I cannot add much to the provided answer. The new restriction was introduced to prevent some invalid queries around the requirements for distinct on and order clauses. Providing these guarantees for composite distinct on clauses is not implemented yet.