/diesel

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

Trying to pass an owned value to `insert` gives an extremely unhelpful error message #249

Closed
sgrif opened this Issue Mar 31, 2016 · 0 comments

Comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@sgrif
@sgrif
Member

sgrif commented Mar 31, 2016

Example case is in #227. When a struct is annotated with #[insertable_into], we derive Insertable for &T. When you attempt to pass an owned T to insert, you'll get a compilation error when attempting to call get_result or similar methods on it. The error message will be along the lines of:

the method `get_result` exists but the following trait bounds were not satisfied: `InsertQuery<(column1, column2), InsertStatement<table, YourStruct>> : QueryFragment<_>`

This is a common enough mistake that we should go out of our way to ensure we have a better error message here. We either need the message to explicitly mention that it expected &T and got T, or just make this case compile.

@sgrif sgrif referenced this issue Mar 31, 2016

Closed

Compilation error on get_result #227

sgrif added a commit that referenced this issue Mar 31, 2016

@sgrif
Improve the error message when `insert` is called with an owned value 
Prior to this commit, the error will occur when you attempt to call
`execute`, `get_result`, or `get_results`. The message will indicate
that those methods don't exist, because `InsertQuery` doesn't implement
`QueryFragment`, with a very long generic type signature. The reason for
this being that `StructName` doesn't implement `Insertable`,
`&StructName` does.

This now handles this common error as quickly and directly as possible.
The error message will now be:

```
error: mismatched types:
 expected `&_`
    found `StructName`
```

This does cause a minor change in functionality, as it becomes
impossible to pass an owned value to `insert`. I don't think this is a
problem, as really the only thing this removes is the ability to
construct an insert statement and the return the query without executing
it, e.g.:

```rust
fn build_insert_query(name: &str) -> Box<QueryFragment<Pg>> {
    let new_user = NewUser { name: name };
    insert(new_user).into(users::table)
}
```

However, this case just doesn't seem like it matters, and I'm fine with
losing support for it.

Fixes #249.
0647988

@sgrif sgrif referenced this issue Mar 31, 2016

Merged

Improve the error message when `insert` is called with an owned value #250

sgrif added a commit that referenced this issue Mar 31, 2016

@sgrif
Improve the error message when `insert` is called with an owned value 
Prior to this commit, the error will occur when you attempt to call
`execute`, `get_result`, or `get_results`. The message will indicate
that those methods don't exist, because `InsertQuery` doesn't implement
`QueryFragment`, with a very long generic type signature. The reason for
this being that `StructName` doesn't implement `Insertable`,
`&StructName` does.

This now handles this common error as quickly and directly as possible.
The error message will now be:

```
error: mismatched types:
 expected `&_`
    found `StructName`
```

This does cause a minor change in functionality, as it becomes
impossible to pass an owned value to `insert`. I don't think this is a
problem, as really the only thing this removes is the ability to
construct an insert statement and the return the query without executing
it, e.g.:

```rust
fn build_insert_query(name: &str) -> Box<QueryFragment<Pg>> {
    let new_user = NewUser { name: name };
    insert(new_user).into(users::table)
}
```

However, this case just doesn't seem like it matters, and I'm fine with
losing support for it.

Fixes #249.
5d8f3e9

@sgrif sgrif closed this in #250 Mar 31, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment