Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prepare a 2.2.8 release #4490

Open
wants to merge 15 commits into
base: 2.2.x
Choose a base branch
from
Open

Conversation

weiznich
Copy link
Member

Ten0 and others added 9 commits February 14, 2025 14:28
I was told "OK I see this error message but my struct already implements Selectable so that's not useful".

As it turns out, this message would sometimes be misunderstood as the `check_for_backend` part only relating to the `QueryableByName` usage, but not to the `Selectable` usage, whereas that is in fact the key point.

Hopefully this new writing will avoid this. :)
Co-authored-by: Georg Semmler <[email protected]>
…ckend]`

Currently when a struct has `#[derive(Selectable)]`, `#[check_for_backend(...)]`, and `embed`s another `Selectable` struct that doesn't have `#[check_for_backend]` but whose `FromSqlRow` and `Selectable` impls don't match with regards to `CompatibleType`, the `#[check_for_backend]` does not point us to which of the embed fields is the culprit, because they are ignored.

It seems that this can be avoided by generating the checks even for `embed` fields.

The check for this was disabled in d6d9260 when the experimented-with approach was "always generating the check on Selectable" with the justification that it was consequently checked by the underlying field's own Selectable checks, before it was decided to instead have the `#[check_for_backend(...)]` attribute, so it seems that this justification was indeed legitimate at the time it was introduced, and doesn't hold anymore now.
This commit turns the `read_*` functions of the `SqliteValue` type into
public functions, which makes it easier for third party crates to access
the underlying sqlite values in a performant way. This enables crates to
not clone for example the string, but rather reuse the string slice we got
from sqlite instead.

This also turns all these functions into methods that require a mutable
reference instead of a shared reference as technically each of those
methods might mutate the underlying value according to the sqlite
documentation.
This commit relaxes a trait constraint that restricted our copy from
implementation for `Insertable` types to 12 columns. That happened
because we used the `Default` impl for tuples from the rust standard
library to construct the column types internally. The standard library
only provides these impl for up to 12 tuple elements. 

The fix is to simply construct that type by calling `Default` for each
of the column types seperatly and then constructing the tuple from that.

I choose to not write a test for that as it doesn't change functionality
in any meaningful way other than just allowing larger tuples.
@weiznich weiznich requested a review from a team February 14, 2025 13:37
This commit prepares a 2.2.8 release that includes the following
changes:

* diesel-rs#4472
* diesel-rs#4484
* diesel-rs#4486
* diesel-rs#4480
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants