Was curious, do others have thoughts on adjusting ...

# exposed

[Adam Jarvis]

Was curious, do others have thoughts on adjusting where to be closer to andWhere?

fun where(predicate: Op<Boolean>): Query {
    where?.let {
        error("WHERE clause is specified twice. Old value = '$it', new value = '$predicate'")
    }
    where = predicate
    return this
}

^ to me, I end up just using andWhere everywhere because of the built in handling of chaining

fun Query.andWhere(andPart: SqlExpressionBuilder.() -> Op<Boolean>) = adjustWhere {
    val expr = Op.build { andPart() }
    if (this == null) expr else this and expr
}

Why always throwing the error for chaining where ?

[Luis Arcos]

I think the purpose of where is make the code look more like SQL, so no chaining is necessary.

.where {
  (StudentAdvisorTable.institutionId eq institutionId)
   .and(StudentAdvisorTable.advisorId eq advisorId)
}

[Adam Jarvis]

so if you want to do fluent chaining of wheres where you have one condition per, you should do andWhere all the time?

[Adam Jarvis]

I guess i'd just prefer to have where respect the null state

Currently, I have a library function that provides a function which accepts an operation on a Query

override suspend fun filter(block: Query.(ThingDatabase) -> Query): List<Thing> {
    val query = block(ThingDatabase.selectAll(), ThingDatabase)
    // other things
    query.andWhere {
        // extra queries
    }
}

I use andWhere because I anticipate the end user using the injected query and using a where on it

[Bogdan]

Це функції з різним сенсом, використовуєтсья так:

Table.selectAll()
    .where { /* code */ }
    .andWhere { }
    .orWhere { }

helps to break up large conditions or is convenient for dynamic queries, the query can be collected in different places in the code

[Adam Jarvis]

Yeah I get that

But in my above example, if you’re passing around the query object as a reference, then you don’t know if the base where has been called yet