Huge Letters Posts - Answer Overflow

Huge Letters

Explore posts from servers

TTCTheo's Typesafe Cult HHono DTDrizzle Team

•Created by Huge Letters on 6/18/2024 in #help

Need a sanity check on my idea for cursor pagination helper

I wanna create a helper to manage cursor-based pagination with Drizzle. To create a cursor your select query needs to contain the columns on which your data is ordered - so you need to include those columns in select. But my concern is that that may cause collisions say

{ 
  name: posts.authorName // this is the data I want to return
  name: posts.name // this was provided by my cursor helper
}

{ 
  name: posts.authorName // this is the data I want to return
  name: posts.name // this was provided by my cursor helper
}

{ 
  postedAt: sql`posts.postedAt`.mapWith(formatDate)
  postedAt: posts.postedAt // this will result in unexpected data format returned
}

{ 
  postedAt: sql`posts.postedAt`.mapWith(formatDate)
  postedAt: posts.postedAt // this will result in unexpected data format returned
}

So I thought what if I would hash the keys provided with the cursor config - these have to be defined only once on app start-up so hashing perf cost is minimal. and then what I will get is something like

{ 
  name: posts.authorName // this is the data I want to return
  dsaffhewqf: posts.name // this was provided by my cursor helper
}

{ 
  name: posts.authorName // this is the data I want to return
  dsaffhewqf: posts.name // this was provided by my cursor helper
}

And then I will also provide the helper which will remove these keys from returned array so that some junk doesn't go to the client The only downside here is that sometimes columns may be returned twice:

{ 
  name: posts.name // this is the data I want to return
  dsaffhewqf: posts.name // this was provided by my cursor helper
}

{ 
  name: posts.name // this is the data I want to return
  dsaffhewqf: posts.name // this was provided by my cursor helper
}

but I'm not sure how bad this is sooo... I just want a sanity check really. Does that sound like an okay-ish idea?

1 replies

DTDrizzle Team

•Created by Huge Letters on 4/6/2024 in #help

Generate SQL statements with Drizzle

I wanna generate statements using Drizzle utilities - for example I have this sql`DROP TRIGGER IF EXISTS ${sql.identifier(triggerName)}` But how do I get the final SQL string from this? db.run(...).getQuery() works but feels counter-intuitive - is that the best way to do that? In case that's important - what I wanna do is create some utils to automate trigger creation a bit - so I could generate trigger statements with Drizzle and then insert those into my migration files

4 replies

DTDrizzle Team

•Created by Huge Letters on 2/3/2024 in #help

Batching statements in MySQL transactions

I'm using Drizzle with Planetscale - I have a transaction which kinda looks like this.

await tx.delete(review).where(eq(review.userId, session.user.id));
await tx.delete(session).where(eq(session.userId, session.user.id));
await tx.delete(account).where(eq(account.userId, session.user.id));
await tx.delete(user).where(eq(user.id, session.user.id));

await tx.delete(review).where(eq(review.userId, session.user.id));
await tx.delete(session).where(eq(session.userId, session.user.id));
await tx.delete(account).where(eq(account.userId, session.user.id));
await tx.delete(user).where(eq(user.id, session.user.id));

The thing is as far as I understand - for every step of the transaction a request is made to my Planetscale database which makes sense given I might need a result of this statement, maybe I need to know how many rows were affected. Because of this this transaction basically makes 4 separate requests to Planetscale. Is there a way to tell Drizzle to just batch this 4 statements as a single request? Given that I don't care about the result of a statement, only if it was successful or not - I only care that these 4 statements are executed in sequence. If that's not possible - is that a limitation of Drizzle, Planetscale or SQL in general?

21 replies

Gaming

Programming