-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent column data: Unexpected conversion failure from Number to BigInt
error when using @prisma/adapter-pg
#23926
Comments
@prisma/adapter-pg
Inconsistent column data: Unexpected conversion failure from Number to BigInt
error when using @prisma/adapter-pg
Hey @chris-addison, I've tried to take a look but the snippets of the schema and typescript you've provided are missing information. Can you please elaborate the relations that you're using in Your I cannot replicate this simply with just the Thanks in advance! |
Apologies for the difficulty @Druue ! This should work for you: Schema: generator client {
provider = "prisma-client-js"
previewFeatures = ["relationJoins"]
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model BaseUser {
id String @id @db.Uuid
intId BigInt @unique
createdAt DateTime @default(now())
updatedAt DateTime @updatedAt
favorites Repository[] @relation("UserFavorites")
ownedRepositories Repository[]
user User @relation("userById", fields: [id], references: [id])
userByIntId User @relation("userByIntId", fields: [intId], references: [intId])
// Indexing intId for faster lookups
@@index([intId(ops: Int8BloomOps)], type: Brin)
}
model User {
id String @id @db.Uuid
correlationId String @unique @db.Uuid
intId BigInt @unique
name String
email String?
locale String?
avatar String?
createdAt DateTime @default(now())
updatedAt DateTime
deletedAt DateTime?
baseUser BaseUser? @relation("userById")
baseUserByIntId BaseUser? @relation("userByIntId")
// Indexing intId for faster lookups
@@index([intId(ops: Int8BloomOps)], type: Brin)
// Indexing email for faster lookups
@@index([email], type: Hash)
} Function: async function getUnsafe(id: string | bigint): Promise<User | null> {
const query = {
where: typeof id === 'bigint' ? { intId: id } : { id },
include: { user: true },
};
const result = await prisma.baseUser.findUnique(query);
if (!result) {
return null;
}
return toUser(result);
}
type PrismaBaseUser = Prisma.BaseUserGetPayload<{ include: { user: true } }>;
function toUser(user: PrismaBaseUser): User {
return {
id: user.id,
intId: user.intId,
name: user.user.name,
email: user.user.email,
avatarUrl: user.user.avatar,
};
} |
Hey, @chris-addison, I took another look, but I still can't reproduce your issue :/ Could you please provide a minimal reproduction for this as I'm not sure what I'm missing I'm using the following schema generator client {
provider = "prisma-client-js"
output = "../node_modules/.prisma/client"
previewFeatures = ["driverAdapters", "relationJoins"]
}
datasource db {
provider = "postgresql"
url = env("TEST_POSTGRES_URI")
}
model BaseUser {
id String @id @db.Uuid
intId BigInt @unique
user User @relation("userById", fields: [id], references: [id])
userByIntId User @relation("userByIntId", fields: [intId], references: [intId])
@@index([intId(ops: Int8BloomOps)], type: Brin)
}
model User {
id String @id @db.Uuid
correlationId String @unique @db.Uuid
intId BigInt @unique
baseUser BaseUser? @relation("userById")
baseUserByIntId BaseUser? @relation("userByIntId")
@@index([intId(ops: Int8BloomOps)], type: Brin)
} And the following typescript code. I tried both import { Prisma, PrismaClient, User } from '.prisma/client'
import { Pool } from "pg";
import { PrismaPg } from "@prisma/adapter-pg";
const connectionString = `${process.env.TEST_POSTGRES_URI as string}`;
const pool = new Pool({ connectionString });
const adapter = new PrismaPg(pool);
const prisma = new PrismaClient({
adapter,
log: ["query"],
});
const id = "123e4567-e89b-12d3-a456-426655440000";
const correlationId = "123e4567-e89b-12d3-a456-426655440001";
const populate = async () => {
const intId = 1;
await prisma.user.create({
data: {
id,
intId,
correlationId,
},
});
await prisma.baseUser.create({
data: {
id,
intId,
},
});
};
async function getUnsafe(id: string | bigint): Promise<User | null> {
const query = {
where: typeof id === "bigint" ? { intId: id } : { id },
include: { user: true },
};
const result = await prisma.baseUser.findUnique(query);
if (!result) {
return null;
}
return toUser(result);
}
type PrismaBaseUser = Prisma.BaseUserGetPayload<{ include: { user: true } }>;
function toUser(user: PrismaBaseUser): User {
return {
id: user.id,
correlationId: user.user.correlationId,
intId: user.intId,
};
}
async function test() {
// const u = await getUnsafe("123e4567-e89b-12d3-a456-426655440000");
const u = await getUnsafe(BigInt(1));
console.log(u);
}
async function main() {
await populate();
return test();
}
main()
.catch((e) => console.error(e))
.finally(async () => {
prisma.$disconnect;
}); The following is when passing
and this with
Setup Information:
|
Thank you for checking! I'll try to put something together this weekend and get back to you on Monday |
@Druue here's the repro: https://github.com/chris-addison/PrismaReproInconsistentColumnData/tree/main I'm using: Here's my system info: npx prisma version
Environment variables loaded from .env
prisma : 5.13.0
@prisma/client : 5.13.0
Computed binaryTarget : darwin-arm64
Operating System : darwin
Architecture : arm64
Node.js : v20.12.2
Query Engine (Node-API) : libquery-engine b9a39a7ee606c28e3455d0fd60e78c3ba82b1a2b (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Schema Engine : schema-engine-cli b9a39a7ee606c28e3455d0fd60e78c3ba82b1a2b (at node_modules/@prisma/engines/schema-engine-darwin-arm64)
Schema Wasm : @prisma/prisma-schema-wasm 5.13.0-23.b9a39a7ee606c28e3455d0fd60e78c3ba82b1a2b
Default Engines Hash : b9a39a7ee606c28e3455d0fd60e78c3ba82b1a2b
Studio : 0.500.0
Preview Features : driverAdapters, relationJoins |
Okay! I can reproduce this! Thank you so much! ✨ (also that removing the
|
unexclude common_types test for pg, neon, and PS
…ctly handle `i64`s (#4883) * One half of the fix for: prisma/prisma#23926 * Unexcludes pg, neon, and PS for the through_relations::common_types test * Instead of receiving pre-handled JSON by DAs, we now expect strings and will perform JSON parsing in Quaint. * Removed special handling for "$__prisma_null" due to the aforementioned * Temporarily disable wasm-benchmarks due to breaking change in engines <-> DA contract. To be re-enabled and re-evaluated in a follow-up PR per convo with @SevInf --------- Co-authored-by: Serhii Tatarintsev <tatarintsev@prisma.io>
…ctly handle `i64`s (#4883) * One half of the fix for: prisma/prisma#23926 * Unexcludes pg, neon, and PS for the through_relations::common_types test * Instead of receiving pre-handled JSON by DAs, we now expect strings and will perform JSON parsing in Quaint. * Removed special handling for "$__prisma_null" due to the aforementioned * Temporarily disable wasm-benchmarks due to breaking change in engines <-> DA contract. To be re-enabled and re-evaluated in a follow-up PR per convo with @SevInf --------- Co-authored-by: Serhii Tatarintsev <tatarintsev@prisma.io>
* One half of the fix for: prisma/prisma#23926 * Unexcludes pg, neon, and PS for the through_relations::common_types test * Instead of receiving pre-handled JSON by DAs, we now expect strings and will perform JSON parsing in Quaint. * Removed special handling for "$__prisma_null" due to the aforementioned * Temporarily disable wasm-benchmarks due to breaking change in engines <-> DA contract. To be re-enabled and re-evaluated in a follow-up PR per convo with @SevInf --------- Co-authored-by: Sophie <29753584+Druue@users.noreply.github.com>
Hi all, I've hit an issue when trying out the
@prisma/adapter-pg
preview feature.I'm using the latest
v5.13.0
and I can resolve the issue by removing the"relationJoins"
from the preview featuresHere's the error I'm seeing in the console:
Here's roughly how I'm calling Prisma:
Here's a subset of my schema:
The text was updated successfully, but these errors were encountered: