The primary type used when walking a Diesel AST during query execution.
Executing a query is generally done in multiple passes. This list includes,
but is not limited to:
- Generating the SQL
- Collecting and serializing bound values (sent separately from the SQL)
- Determining if a query is safe to store in the prepared statement cache
When adding a new type that is used in a Diesel AST, you don't need to care
about which specific passes are being performed, nor is there any way for
you to find out what the current pass is. You should simply call the
relevant methods and trust that they will be a no-op if they're not relevant
to the current pass.
Call this method whenever you pass an instance of AstPass
by value.
Effectively copies self
, with a narrower lifetime. When passing a
reference or a mutable reference, this is normally done by rust
implicitly. This is why you can pass &mut Foo
to multiple functions,
even though mutable references are not Copy
. However, this is only
done implicitly for references. For structs with lifetimes it must be
done explicitly. This method matches the semantics of what Rust would do
implicitly if you were passing a mutable reference
Mark the current query being constructed as unsafe to store in the
prepared statement cache.
Diesel caches prepared statements as much as possible. However, it is
important to ensure that this doesn't result in unbounded memory usage
on the database server. To ensure this is the case, any logical query
which could generate a potentially unbounded number of prepared
statements must call this method. Examples of AST nodes which do this
are:
SqlLiteral
. We have no way of knowing if the SQL string was
constructed dynamically or not, so we must assume it was dynamic.
EqAny
when passed a Rust Vec
. The IN
operator requires one bind
parameter per element, meaning that the query could generate up to
usize
unique prepared statements.
InsertStatement
. Unbounded due to the variable number of records
being inserted generating unique SQL.
UpdateStatement
. The number of potential queries is actually
technically bounded, but the upper bound is the number of columns on
the table factorial which is too large to be safe.
Push the given SQL string on the end of the query being constructed.
impl<Left, Right, DB> QueryFragment<DB> for And<Left, Right>
where
DB: Backend,
Left: QueryFragment<DB>,
Right: QueryFragment<DB>,
{
fn walk_ast(&self, mut out: AstPass<DB>) -> QueryResult<()> {
self.left.walk_ast(out.reborrow())?;
out.push_sql(" AND ");
self.right.walk_ast(out.reborrow())?;
Ok(())
}
}
Push the given SQL identifier on the end of the query being constructed.
The identifier will be quoted using the rules specific to the backend
the query is being constructed for.
Push a value onto the given query to be sent separate from the SQL
This method affects multiple AST passes. It should be called at the
point in the query where you'd want the parameter placeholder ($1
on
PG, ?
on other backends) to be inserted.
Convert self
to an expression for Diesel's query builder. Read more
Convert &self
to an expression for Diesel's query builder. Read more
🔬 This is a nightly-only experimental API. (try_from
)
The type returned in the event of a conversion error.
🔬 This is a nightly-only experimental API. (try_from
)
Immutably borrows from an owned value. Read more
🔬 This is a nightly-only experimental API. (get_type_id
)
this method will likely be replaced by an associated static
🔬 This is a nightly-only experimental API. (try_from
)
The type returned in the event of a conversion error.
🔬 This is a nightly-only experimental API. (try_from
)
Mutably borrows from an owned value. Read more