Count returns not the total count but the count of returned results

[lishine]

I mean if the limit=5 and results length is 5, count = 5
Is it intended?
What I expect is count = number of filtered rows without limit

    type Order @model(table: "orders", pk: "id") {
        id: ID!
        clientId: ID!
        clientUserId: ID!
        createdAt: String
        status: String
        paymentId: String
        amount: String
        productCode: String
        quantity: String
    }

    type Query @sqlmancer(dialect: POSTGRES, transformFieldNames: SNAKE_CASE) {
        hello(name: String): String
        isAuth: AuthPayload!
        orders: Order @many @paginate
    }

        async orders(_, __, { sql, client }, info) {
            isAuth
            return client.models.Order.paginate().count().selectAll().resolveInfo(info).execute()
        },

[lishine]

I adapted my project to the 0.2.1 release
And it works great, aside from the count.
I use @many, @paginate, typescript generation

It could me mentioned in the docs, how to integrate types:

client.ts:
import Knex from 'knex'
import { createSqlmancerClient } from 'sqlmancer'
import { SqlmancerClient } from './generated'

const knex = Knex({
    client: 'pg',
    connection: process.env.PG_CONNECTION_STRING,
})
export const client: SqlmancerClient = createSqlmancerClient('./src/sqlmancer/schema.ts', knex)

npx sqlmancer generate ./src/sqlmancer/schema.ts ./src/sqlmancer/generated.ts

context.d.ts:
import { Request, Response } from 'express'
import { SqlmancerClient } from '../sqlmancer/generated'

export type Context = { sql: any; req: Request; res: Response; client: SqlmancerClient }

server.ts:
import { makeSqlmancerSchema } from 'sqlmancer'

import { resolvers } from './resolvers'
import { schema } from '~/sqlmancer/schema'
import { client } from '~/sqlmancer/client'

    const server = new ApolloServer({
        schema: makeSqlmancerSchema({
            typeDefs: schema,
            resolvers: resolvers,
        }),
        context: ({ req, res }) => {
            return {
                sql,
                client,
                req,
                res,
            }
        },
        debug: false,
    })

I still use one schema file because of code-gen.
I can try to write code-gen plugin ?

[danielrearden]

The original intent behind the count aggregate field was to answer questions like "how many orders have a status of DELIVERED?"

query {
  orders(where: { status: { equal: "DELIVERED" } }) {
    aggregate {
      count
    }
  }
}

It sounds like we need to add a separate totalCount field, probably next to hasMore instead of inside the aggregate object, that would return the count without the limit applied.

[danielrearden]

I actually started working on a graphql-codegen plugin already. My intent is to replace the CLI entirely with it. The plugin could optionally generate the resolvers using the existing typescript-resolvers plugin as well to make the whole DX better.

[lishine]

So I understand the intend that functions that are inside aggregate to operate with all the arguments applied including limit and offset. And it is useful in case that results are not requested. Because if results are requested, it could be just calculated by the requester.
You intend to put totalCount outside aggregate. And it would not be affected by offset and limit. BTW hasMore is affected by offset. And these specs are implicit, is it good enough?
Furthermore, would there be need to calculate totalAvg/totalMin/totalMax ?
Considering the above, hasura's API seems reasonable. All can be done in one go. Just the where: $where need to be specified in each.

query {
   orders(limit, where)
   aggregate_orders(limit, where)
   aggregate_orders(nolimit, where)
}

[lishine]

Maybe like this

query {
  orders(where: { status: { equal: "DELIVERED" } }) {
    aggregate {
      count
    }
    aggregateTotal {
      count
    }
  }
}

[lishine]

Or to be explicit:

query {
  orders {
    results(where: $where, offset: $offset, limit: $limit)
    hasMore(where: $where, offset: $offset)
    aggregate(where: $where, offset: $offset, limit: $limit ) {
      count
    }
    aggregateTotal(where: $where) {
      count
    }
  }
}

[danielrearden]

totalCount would really be more a convenience. It's already possible to do something like

query($where: OrderWhere!, $limit: Int!) {
  orders(where: $where, limit: $limit) {
    results {
      id
    }
  }
  allOrders: orders(where: $where) {
    aggregate {
      count
    }
  }
}

Definitely need to at least document the usage better.

By the way, I forgot to mention, you can simplify this:

client.models.Order.paginate().count().selectAll().resolveInfo(info).execute()

to just

client.models.Order.paginate().resolveInfo(info).execute()

resolveInfo will append count and select and whatever other methods to the builder as needed depending on what fields are actually requested

[lishine]

Thanks.

The above

query($where: OrderWhere!, $limit: Int!) {
  orders(where: $where, limit: $limit) {
    results {
      id
    }
  }
  allOrders: orders(where: $where) {
    aggregate {
      count
    }
  }
}

Indeed I do it now - as ordersCount. But it has to be added to the scheme.

[lishine]

And btw date now returns a string - cool!

[lishine]

Indeed I do it now - as ordersCount. But it has to be added to the scheme.

My mistake, you mean allOrders is an alias. Cool idea, then all good, no need for totalCount and such

[lishine]

So essentially this issue can be closed

[danielrearden]

I'm still wondering if adding totalCount might make sense. It's not uncommon to see that field exposed in, for example, Relay connections.

[lishine]

Each table will use this. At least, totalCount will simplify a bit the query.
But if it is related to Relay, it can be done together with #46

[lishine]

It can be right now partly compatible with relay :))
hasMore -> pageInfo { hasNextPage }
results -> edges