jeremy Posts - Answer Overflow

jeremy

Explore posts from servers

•Created by jeremy on 6/1/2024 in #help-and-questions

Raw SQL generated for cursor using libsql issue

To start with I am using:

"@libsql/client": "0.6.1",
"@prisma/adapter-libsql": "5.14.0",
"@prisma/client": "5.14.0",
"prisma": "5.14.0",

"@libsql/client": "0.6.1",
"@prisma/adapter-libsql": "5.14.0",
"@prisma/client": "5.14.0",
"prisma": "5.14.0",

I am handling a cursor-based pagination. My code looks like this:

const take = constants.pagination.limit + 1;
const cursor = input.after ? { id: decodeCursor(input.after) } : undefined;
const skip = input.after ? 1 : 0;

const data = await this.prismaService.user.findMany({
  take,
  cursor,
  skip,
  orderBy: {
    createdAt: 'desc',
  },
  select: {
    id: true,
  }
})

const take = constants.pagination.limit + 1;
const cursor = input.after ? { id: decodeCursor(input.after) } : undefined;
const skip = input.after ? 1 : 0;

const data = await this.prismaService.user.findMany({
  take,
  cursor,
  skip,
  orderBy: {
    createdAt: 'desc',
  },
  select: {
    id: true,
  }
})

When fetching the first batch of items, with after argument being null, I'm successfully getting the data. The raw generated SQL looks like this:

SELECT `main`.`User`.`id` FROM `main`.`User` ORDER BY `main`.`User`.`createdAt` DESC LIMIT 6 OFFSET 0

SELECT `main`.`User`.`id` FROM `main`.`User` ORDER BY `main`.`User`.`createdAt` DESC LIMIT 6 OFFSET 0

However, when trying to get the next batch based on the cursor, I'm getting an error from libSQL RESPONSE_TOO_LARGE: Response is too large. When looking at the generated SQL it looks like this:

SELECT `main`.`User`.`id` FROM `main`.`User` AND `main`.`User`.`createdAt` <= (SELECT `main`.`User`.`createdAt` FROM `main`.`User` WHERE (`main`.`User`.`id`) = (6))) ORDER BY `main`.`User`.`createdAt` DESC LIMIT -1 OFFSET 0

SELECT `main`.`User`.`id` FROM `main`.`User` AND `main`.`User`.`createdAt` <= (SELECT `main`.`User`.`createdAt` FROM `main`.`User` WHERE (`main`.`User`.`id`) = (6))) ORDER BY `main`.`User`.`createdAt` DESC LIMIT -1 OFFSET 0

I believe the -1 is a bug and the proper limit is not being applied correctly here. Does anyone have a pointer on how I can debug this locally and maybe local patch it?

4 replies

CDCloudflare Developers

•Created by jeremy on 4/24/2024 in #workers-help

Subrequests metrics

Hi there, I wrote a workers to cache request from my graphql endpoint. I mostly following the example here https://blog.cloudflare.com/introducing-the-workers-cache-api-giving-you-control-over-how-your-content-is-cached As a result I correctly get cached request from the Cloudflare Cache API with status "cf-cache-status: HIT". However, if I go to the analytics dashboard to "Workers (per zone) > Subrequests > Cached requests" it says 0. "Total requests" is correctly populated with the request I made. I'm looking at the documentation here https://developers.cloudflare.com/workers/observability/metrics-and-analytics/#subrequests and the way I'm doing it should be correct. Any pointers on why it's not showing any requests cached?

12 replies

Gaming

Programming