A safe, extensible ORM and Query Builder for Rust – For feature requests and longer questions also see https://github.com/diesel-rs/diesel/discussions/categories/q-a
i am using diesel 1.45
@Urhengulas I would probably just try to call
Connection::begin_test_connection()for each connection on pool creation via ther2d2::CustomizeConnectiontrait.
Generally speaking: I think a guide how to write tests involving diesel is certainly something that would be a welcome addition for our web page.
@weiznich Thanks. That sounds like an idea. If I come up with a good pattern I might send a description PR for the website :)
Never mind i managed to figure out the issue. It is due to the Table Schema not having the variables in the same order as the struct OR the struct missing variables that exist within the table schema. Would be nice if it could use the struct to make the connection and mappings instead of the schema.
p::plate
.select(m::measurement.select(count_star()).filter(m::plate_id.eq(p::id)))
.load::<i64>(&conn)
2 replies
btw this is only the start of a query, I would still inner join
plate with other tables and select several more columns
Well what i mean @weiznich is instead of having to use the schema like this example
diesel::table! {
use crate::gametypes;
use diesel::sql_types::*;
players (uid) {
uid -> BigInt,
name -> Text,
address -> Text,
pos -> gametypes::PosType,
vital -> Array<Integer>,
indeath -> Bool,
}
}
#[derive(Debug, PartialEq, Queryable, Insertable, Associations, Identifiable)]
#[table_name = "players"]
#[primary_key(uid)]
pub struct PGPlayerWithID {
uid: i64,
name: String,
address: String,
pos: Position,
vital: Vec<i32>,
indeath: bool,
}
let pgplayer = players::table.filter(players::uid.eq(user.accid)).first::<PGPlayerWithID>(conn)?;
that you could either have it map the table Select based on the components in the structure and use the structure directly to do the SQL Query. like this.
diesel::table! {
use crate::gametypes;
use diesel::sql_types::*;
players (uid) {
uid -> BigInt,
name -> Text,
address -> Text,
pos -> gametypes::PosType,
vital -> Array<Integer>,
indeath -> Bool,
}
}
#[derive(Debug, PartialEq, Queryable, Insertable, Associations, Identifiable)]
#[table_name = "players"]
#[primary_key(uid)]
pub struct PGPlayerWithID {
uid: i64,
name: String,
}
let pgplayer = PGPlayerWithID::select.filter(players::uid.eq(user.accid)).first::<PGPlayerWithID>(conn)?;
@genusistimelord How would you support more complex select clauses in your example? It's important to support queries that do not only "just" select some fields as part of the select clause, but have more complex expressions there. For example such queries as in the example above your current post. (There is #2367 which implements something like that, but that's nothing that's on top of my priority list.)
Yeah i was mostly just offering my Idea's on this. The main thing would be to support a single Schema with additional structs that could return different amounts of data based on the struct compared to the schema. for more advanced i would still recommend using the schema directly. just thinking of this as writing less code for a large project.
but its not important.
That shouldn't mean that this wouldn't be something that can be useful for anyone. I'm just not sure if this should be really part of diesel itself, or should there be some kind of "high-level" crate that uses diesel internally and provides an interface that matches more classical ORM 's. If someone steps up to write such an crate I would definitively try to over some advice and help for implementation there.
I think you doesn't need that much macros for such a project. More likely that you need to define a whole lot of traits and write some generic code + maybe one or two "simple" derive macros (but they are really simple, just take some rust code and generate some rust code, that's not any more complex than writing normal rust code)
I think the more complex part is to decide how the "public" API of such a crate should look like and how to avoid common ORM problems like N+1 queries in such an API.
I think @pksunkara Is working on something like that as well, so maybe you could ask them on their approach and join forces there?
I think maybe for something like this rather that relying on a full blown query hierarchy it be better to just add a derive that builds a players::table.select((players.uid, players.name)) that the end user could simply just use the rest of regular diesel along with it
so you could do
PGPlayerWithID::select() and the rest would be regular diesel commands
PGPlayerWithID::select() and the rest would be regular diesel commands
For that see #2367. As written before: It's not a priority for myself, but I would be happy to accept a complete PR there.
I think maybe for something like this rather that relying on a full blown query hierarchy it be better to just add a derive that builds a players::table.select((players.uid, players.name)) that the end user could simply just use the rest of regular diesel along with it
I have actually finished implementing support for the above in my ORM lib (on top of diesel) using rust macros. I am currently working on solving this issue for INSERT and UPDATE. And then will move on to associations (I have a vague idea on how to solve the n+1 problem)
It uses diesel master
An example on how it is used in a web app, https://github.com/pksunkara/reign/blob/master/examples/full/src/controllers/articles.rs
It seems like a bug that you can use
[u8; 8] in a derive Queryable struct but not a derive Insertable struct (you get an error about it not implementing Expression for the latter). I've worked around it with a serialize_as wrapper for now. Should I file a github issue or is there an underlying cause here I haven't thought about?
With diesel features=["postgres"] :
#[macro_use]
extern crate diesel;
table! {
examples (id) {
id -> Int4,
bytes -> Bytea,
}
}
// Compiles
#[derive(Queryable)]
struct Example {
id: i32,
bytes: [u8; 8],
}
// Doesn't compile
#[derive(Insertable)]
#[table_name = "examples"]
struct NewExample {
bytes: [u8; 8],
}
let me look at an example without postgres..
thanks
for now, my code looks like:
table
.filter(available.eq(query.available()))
.limit(query.limit())
.offset(query.offset());diesel is AWESOME~~~