Closed aes closed 8 months ago
Looking at the front page example:
#[derive(QueryableByName)]
#[diesel(table_name = users)]
struct User {
id: i32,
name: String,
organization_id: i32,
}
// Using `include_str!` allows us to keep the SQL in a
// separate file, where our editor can give us SQL specific
// syntax highlighting.
sql_query(include_str!("complex_users_by_organization.sql"))
.bind::<Integer, _>(organization_id)
.bind::<BigInt, _>(offset)
.bind::<BigInt, _>(limit)
.load::<User>(&mut conn)?;
Note that we're trusted to know the order and type of args going into the query, but we absolutely must use a fruity struct to get anything out. This seems really weird to me.
I'm closing this as this is totally the wrong place for such a discussion (This is the issue tracker for the web page, not for diesel itself. If you are interested in a real discussion fell free to open a new discussion thread in the diesel repo. (I would also suggest that you don't use sarcastic language there to talk about the work of other people if you expect any answer).
Hi
I was trying to write a few trivial tests and one simple thing is the typical "SELECT 1" commonly used for a connectivity check. (It's semi-popular because it doesn't assume any schema, or even that there's anything in the database.)
This turns out to be shockingly painful.
And that's a problem. "Ur dumb" doesn't cut it here. It could be as simple as a few lines in the docs, (because I am dumb,) it could be an implementation of
Queryable
for a few basic types, or... The sky is the limit really.Examples of things tried:
This one is fun, it says "use of undeclared crate or module
wrappers
". Like, wait, WAT, did you make that name out of thin air? Oh, it's lowercase of a pluralization, gotcha.Anyway, I give up on using Diesel at this point. If I find a corner this sharp this quickly, there's bound to be more. (This makes me sad, it looks super nice otherwise.)