Struct diesel::query_builder::AstPass

pub struct AstPass<'a, 'b, DB>where
    DB: Backend,
    DB::QueryBuilder: 'a,
    <DB as HasBindCollector<'a>>::BindCollector: 'a,
    DB::MetadataLookup: 'a,
    'b: 'a,{ /* private fields */ }

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.

Implementations

impl<'a, 'b, DB> AstPass<'a, 'b, DB>where
    DB: Backend,
    'b: 'a,

pub fn reborrow(&mut self) -> AstPass<'_, 'b, DB>

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

pub fn unsafe_to_cache_prepared(&mut self)

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.

pub fn push_sql(&mut self, sql: &str)

Push the given SQL string on the end of the query being constructed.

Example

impl<Left, Right, DB> QueryFragment<DB> for And<Left, Right>
where
    DB: Backend,
    Left: QueryFragment<DB>,
    Right: QueryFragment<DB>,
{
    fn walk_ast<'b>(&'b self, mut out: AstPass<'_, 'b, DB>) -> QueryResult<()> {
        self.left.walk_ast(out.reborrow())?;
        out.push_sql(" AND ");
        self.right.walk_ast(out.reborrow())?;
        Ok(())
    }
}

pub fn push_identifier(&mut self, identifier: &str) -> QueryResult<()>

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.

pub fn push_bind_param<T, U>(&mut self, bind: &'b U) -> QueryResult<()>where
    DB: HasSqlType<T>,
    U: ToSql<T, DB>,

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.