A modern programming language that makes developers happier.

kotlinlang

The .count() function looks a little strange with new DSL in 0.46.0.

For example:
```Table
    .selectAll()
    .where { Table.someColumn.eq(someValue) }
    .count()```
```Table
    .select(Table.id)
    .where { Table.someColumn.eq(someValue) }
    .count()```
Both will produce the same query with COUNT(*). So, .selectAll, .select in this case are required, but redundant. I know it's possible to do .select(Table.id.count()), but adding .count at the end of the statement is just easier.

Are you suggesting the SQL produced is always `select count(*)` , and not `select count(id)`

Long ago I read that `select count(*)`  performs poorly , and use `select count(1)` or `select count(id)`  instead

In my opinion, keeping the DSL close to SQL , makes adoption easy.  I found Hibernate HQL to be unfamiliar and felt alien. I never managed to learn it at all.

No, I'm just saying that with new changes in 0.46.0, in that particular case, `.select, .selectAll` have no effect, but are still required.

In terms of performance, in these simple cases, I don't think there any difference between `count(*)` and `count(1)`

okay, by the way, do you know how to log the generated SQL ?

Using debug level for `Exposed` logger should be enough

Hi <@USWVD21L6> and thanks for trying out the new query DSL.

The behavior of `count()` itself hasn't changed in that `Table.selectAll()` and `Table.select(Table.id)` do produce the same sql `SELECT COUNT(*) ...`, much in the same way that using `slice()` with the old DSL provided the same redundancy by generating the same sql:
```Table
    .select { Table.someColumn eq someValue }
    .count()

Table
    .slice(Table.id)
    .select { Table.someColumn eq someValue }
    .count()
```
The difference does lie in that `select()` and `selectAll()` are required because they have an important purpose as the only starting points for the instantiation of a `Query`.
This restriction complies with the start of standard `SELECT` syntax and removes the ambiguity of the old `select { }`, i.e. SELECT _what?_ ... _where?_ ..., by making the intent of each step explicitly readable.
Their effect is to allow query builder functions to be chained to the same instance.

Given the placement of `COUNT` in the syntax, it would be nice to do something like:
```Table
    .selectCountAll()
    .where { Table.someColumn eq someValue }
```
But this is currently not feasible due to the reliance on `count()` being a terminal operation in a query builder.

Ideally, would you prefer to see an alternative that uses a dual-purpose function, instead of having to chain an instantiator with a builder function? Something like:
```// before
Table
    .selectAll()
    .where { Table.someColumn eq someValue }
    .count()

// after
Table
    .selectAllWhere { Table.someColumn eq someValue }
    .count()
```
If so, please don't hesitate to open a feature request on <https://youtrack.jetbrains.com/newIssue?project=EXPOSED&c=Type%20Feature&draftId=25-4449790|YouTrack> so other users can upvote.

I like your `selectCountAll` idea. I always found that placing `count()` at the end of the statement to be weird considering it is part of the Select clause is SQL syntax.

Fully agree with Luis. Considering the new approach to DSL, which is closer to SQL, I think that `.count()` at the end looks odd, but it's easier to use than `.select(Table.id.count())`. I think `.selectCountAll()` would solve this problem.