Triggers, subscriptions and views support

[mickiewicz]

First of all I would like to say you have done a great job with Kysely 👍
Currently we are looking for an ORM or query builder for our new project. At the very beginning we have considered mikro-om or plain Knex. Mostly because they are feature rich but unfortunately with very limited support for Typescript. I really like Kysely and I would like to give it a try but I would like to ask if there is already a support for triggers, subscriptions and views? I can’t find anything in the documentation that might cover this topics. Is the raw query the only way how it can be currently done?

[koskimas]

There's currently no support for triggers or subscriptions.

Trigger support would always rely on raw SQL. The other option would be to reimplement the whole plpgsql language in javascript. We could add helpers for all the creation boilerplate at some point though.

Views should be fully supported. The schema module has the createView method for creating views and views can be used just like any table.

[mickiewicz]

@koskimas is it possible to retrieve client/pool instance so I can subscribe to notifications?

[koskimas]

Nope, not possible. But if you implement your own dialect, you can make it possible.

[thelinuxlich]

how do I create triggers with Kysely? (custom SQL tag)

[igalklebanov]

how do I create triggers with Kysely? (custom SQL tag)

Try this..

const db = new Kysely(...);

await sql`YOUR_SQL_HERE`.execute(db);

[itsramiel]

how do I create triggers with Kysely? (custom SQL tag)

Try this..

const db = new Kysely(...);

await sql`YOUR_SQL_HERE`.execute(db);

This should typically be added in a migration file right?

[mickiewicz]

Yes, if you would like to create a trigger, then you should put your sql in the migration file. As an alternative you can also create a subscriber in a place where you are creating db connection. With such subscriber you can an emit events and in other places listen to that events.

[itsramiel]

Yes, if you would like to create a trigger, then you should put your sql in the migration file. As an alternative you can also create a subscriber in a place where you are creating db connection. With such subscriber you can an emit events and in other places listen to that events.

Thanks for the reply!