DT
Drizzle Team•5mo ago
lsof

rqb v2: `with` is always nullable

I'm trying to migrate to rqb v2, but it seems that related tables in with are always nullable. Here's my query: 
const organizations = await db.query.organization.findMany({
    with: {
        address: true
    }
});
// organizations[0].address should NOT be nullable,
// but according to TypeScript, it is
const organizations = await db.query.organization.findMany({
    with: {
        address: true
    }
});
// organizations[0].address should NOT be nullable,
// but according to TypeScript, it is
My schema: 
export const address = pgTable("address", (t) => ({
    id: t.integer().primaryKey().generatedAlwaysAsIdentity()
}));
export const organization = pgTable("organization", (t) => ({
    id: t.integer().primaryKey().generatedAlwaysAsIdentity(),
    addressId: t
        .integer()
        .notNull() // <-- in rqb v1, this was enough
        .references(() => address.id)
    })
);
export const address = pgTable("address", (t) => ({
    id: t.integer().primaryKey().generatedAlwaysAsIdentity()
}));
export const organization = pgTable("organization", (t) => ({
    id: t.integer().primaryKey().generatedAlwaysAsIdentity(),
    addressId: t
        .integer()
        .notNull() // <-- in rqb v1, this was enough
        .references(() => address.id)
    })
);
Note that addressId is .notNull(). These are my relations: 
// Relations
export const relations = defineRelations(schema, (r) => ({
    organization: {
        address: r.one.address({
            from: r.organization.addressId,
            to: r.address.id,
        }),
    },
    address: {
        organizations: r.many.organization(),
    },
}));
// Relations
export const relations = defineRelations(schema, (r) => ({
    organization: {
        address: r.one.address({
            from: r.organization.addressId,
            to: r.address.id,
        }),
    },
    address: {
        organizations: r.many.organization(),
    },
}));
Is this a bug in rqb v2 or is my code missing something?
4 Replies
lsof
lsofOP•5mo ago
Looks like this behavior is due to a missing optional: false , which seems to be new in rqb v2 (thanks for your post in #rqb-v2 , @Kaeon) This feels redundant, though. Why is this not inferred?
Sillvva
Sillvva•5mo ago
My guess on the "why" is because your relational id being not nullable does not guarantee the referenced table has a matching record. Foreign key constraints can help guarantee this in your db, but drizzle doesn't know about those constraints. For example, if you don't have FKC set up, and you have addressId: 1 in your organization table, but address with id: 1 was deleted. Your above query would return address: null.
lsof
lsofOP•5mo ago
I understand, but my point is that foreign key constraints can be inferred from the drizzle schema using .references(...), like rqb v1 already did, no? Up to this point, drizzle-kit has created the FKC for .references(...) in the DB on push. Is the intent to change this behavior and thus allow for "soft" FKC that are not part of the DB schema, but only part of the drizzle schema? It might be due to my lack of experience, but I'm having trouble seeing the use case for this.
Kaeon
Kaeon•5mo ago
I'm only using optional false now after assuring the FK is defined with notNull() , which could indeed be automatic I think?

Did you find this page helpful?