BluePin Comments - Answer Overflow

I thought about using this to make my queries super fast using the least amount of CPU and RAM possible. However, I found a problem. Since the prepared queries are within a variable and they usually use the db variable, I can’t use it unless I put ALL the variables with the prepared queries, which can easily be 10,000 different queries for various contexts and needs.

import * as usersPrepared from ".db/PreparedStatements/users"
import * as accountsPrepared from ".db/PreparedStatements/acconts"
export const createTRPCContext = async (opts: { headers: Headers }) => {
  return {
    db,
    ...usersPrepared,
    ...accountsPrepared
    ...opts,
  };
};

import * as usersPrepared from ".db/PreparedStatements/users"
import * as accountsPrepared from ".db/PreparedStatements/acconts"
export const createTRPCContext = async (opts: { headers: Headers }) => {
  return {
    db,
    ...usersPrepared,
    ...accountsPrepared
    ...opts,
  };
};

How can I solve this? Is there a way to integrate Drizzle’s Prepared Statements with the tRPC context without having to put all the prepared queries in the context? Any guidance or suggestions would be greatly appreciated. Thank you. Sorces: https://orm.drizzle.team/docs/perf-queries#prepared-statement https://trpc.io/docs/server/context#creating-the-context Another thing is, if you put all the prepared statements in the context, does it have a memory limit on how long it can stay within the context? Is it bad to put too many things in context?

2 replies

TtRPC

•Created by BluePin on 3/22/2024 in #❓-help

“Integrating Drizzle Prepared Statements with tRPC Context”

Another thing is, if you put all the prepared statements in the context, does it have a memory limit on how long it can stay within the context? Is it bad to put too many things in context?

4 replies

TtRPC

•Created by BluePin on 3/22/2024 in #❓-help

“Integrating Drizzle Prepared Statements with tRPC Context”

Sorces: https://orm.drizzle.team/docs/perf-queries#prepared-statement https://trpc.io/docs/server/context#creating-the-context

4 replies

TtRPC

•Created by BluePin on 3/22/2024 in #❓-help

“Integrating Drizzle Prepared Statements with tRPC Context”

import * as usersPrepared from ".db/PreparedStatements/users"
import * as accountsPrepared from ".db/PreparedStatements/acconts"
export const createTRPCContext = async (opts: { headers: Headers }) => {
  return {
    db,
    ...usersPrepared,
    ...accountsPrepared
    ...opts,
  };
};

import * as usersPrepared from ".db/PreparedStatements/users"
import * as accountsPrepared from ".db/PreparedStatements/acconts"
export const createTRPCContext = async (opts: { headers: Headers }) => {
  return {
    db,
    ...usersPrepared,
    ...accountsPrepared
    ...opts,
  };
};

4 replies

DTDrizzle Team

•Created by BluePin on 3/22/2024 in #help

Does anyone know how to write `::character varying` correctly in schema?

2 replies

DTDrizzle Team

•Created by markk on 3/22/2024 in #help

Nullable IDs

Bug? I think the safest thing is to use .notNull()

8 replies

DTDrizzle Team

•Created by matukosan on 12/11/2023 in #help

How to handle partitions?

I just used introspect to pull up a bench. The partitions came as separate tables... this is really bad. tb_example_1 tb_example_2 tb_example_3 tb_example_4

2 replies

DTDrizzle Team

•Created by textYash on 3/21/2024 in #help

How to write a good username schema?

{
  id: bigserial("id", { mode: "bigint" }).notNull().primaryKey()
}

{
  id: bigserial("id", { mode: "bigint" }).notNull().primaryKey()
}

6 replies

DTDrizzle Team

•Created by textYash on 3/21/2024 in #help

How to write a good username schema?

There is a difference in the ability of banks to share information. When you use integer the identification process is 123 to 123. Easy. But for String it is textYash t 2000 results te 1500 tex 100 text 2 results textY 1 result textYash result confirmed. That's not exactly how it does it... But it's an optimized Char dataTypes search algorithm. That's why a string is an "Array[]" of char. So you have to parce each character. an integer is stored in just one memory address. So it is faster to compare. And if you use bigint serial for id and use it with index activated, it will be super quick to find this user. If you have table partitioning logic you can still create user partitions. All this applied will make a super fast search. Furthermore, using unic in primarykey is not necessary. Because no primary key can be repeated, that is, it is already unique and null cannot be inserted in the primary key, so it is necessary to use .notNull. That said, good luck.

6 replies

Gaming

Programming