Improve relations recipe

[koskimas]

I don't know why it took so long to figure out that this is how we should tell people to write their relation helper functions:

function pets(foreignKey: Expression<string>) {
  return jsonArrayFrom(
    db.selectFrom('pet')
      .select(['pet.id', 'pet.name'])
      .where('pet.owner_id', '=', foreignKey)
      .orderBy('pet.name')
  )
}

Instead of the old suggestion:

function pets(eb: ExpressionBuilder<DB, 'person'>) {
  return jsonArrayFrom(
    eb.selectFrom('pet')
      .select(['pet.id', 'pet.name'])
      .whereRef('pet.owner_id', '=','person.id')
      .orderBy('pet.name')
  )
}

The former only takes in the dependencies (the foreign key) as an argument and provides just as much type-safety as the old way.

The old way had a number of issues: It specified the exact ExpressionBuilder type, which doesn't work if the parent query has any joins or uses an alias for the person table.

Another benefit is that we can work with the db type instead of the more complex eb type. Especially if the relations are deeply nested, the deepest eb types become really slow, as they inherit their DB types from the parent ExpressionBuilders and etc.

Also, this is in line with how we instruct people to write any helper functions:

function doStuff(expr: Expression<number>) { 
  return sql<T>`something that uses ${expr}`
}

Another benefit: You can't accidentally select stuff from the parent scope.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
kysely	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 16, 2024 2:14pm

[igalklebanov]

LGTM! 🚀

[igalklebanov]

Hey 👋

Shouldn't this land on master instead of the version branch?

[koskimas]

Shouldn't this land on master instead of the version branch?

True. I'll rebase.