尧图网站建设 
Supabase Database Webhooks 怎么在表格 INSERT、UPDATE、DELETE 事件上触发外部系统【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase你有一个具体任务当数据库里某张表发生行变更时自动通知一个外部系统——把新数据推送给外部 API、同步到其他服务或触发下游流程。Supabase 的 Database Webhooks 就是为此设计的你选定一张表和要挂钩的事件INSERT、UPDATE、DELETE中的一种或多种之后每当对应事件发生数据库就会向外发送一个带 JSON payload 的 HTTP 请求。所有事件都在数据库行变更之后触发。它的底层实现值得先了解Database Webhooks 是对 pg_net 扩展的触发器的封装。pg_net 是异步的因此长耗时的网络请求不会阻塞你的数据库写入。需要注意 pg_net API 目前处于 beta函数签名可能会变化。前提条件一个 Supabase 项目且目标表已存在于数据库例如publicschema 下的某张表。一个可访问的外部 HTTP 端点用于接收 Webhook 请求。通过 Dashboard 创建的 Webhook 可以以POST或GET发送 JSON payload。如果你选择 SQL 方式创建则直接使用 SQL Editor 执行触发器语句即可。方式一在 Dashboard 创建 Webhook主路径这是文档给出的最短路径在 Dashboard 的 Webhooks 页面创建一个新的 Database Webhook。为你的 Webhook 命名。选择要挂钩的表。勾选一个或多个要挂钩的事件表插入inserts、更新updates或删除deletes。由于 Webhook 本质上是数据库触发器同样一个 Webhook 也可以直接用 SQL 创建见下一节。方式二直接用 SQL 创建触发器Database Webhooks 文档给出的 SQL 示例create trigger my_webhook after insert on public.my_table for each row execute function supabase_functions.http_request( http://host.docker.internal:3000, POST, {Content-Type:application/json}, {}, 1000 );五个参数按示例依次为目标端点 URL、请求方法POST、请求头JSON 字符串、请求体JSON 字符串{}以及文档示例中的1000文档未解释该参数的含义照抄示例即可。示例中的表名my_table、URL 端口等替换为你自己的表和目标端点。上面的示例挂在after insert上。要响应UPDATE或DELETE把触发器条件换成after update或after delete——pg_net 文档中的触发器示例就展示了after update on table_name的写法。可选分支如果你不想用文档默认的 payload 结构而是自定义请求内容例如把old_row和new_row一起打包发送可以自己写一个返回trigger的函数并在其中调用net.http_postpg_net 文档的 Execute pg_net in a trigger 一节提供了完整示例。外部系统收到的 payload 结构payload 由底层表记录自动生成三种事件的结构如下源文档给出的 TypeScript 类型type InsertPayload { type: INSERT table: string schema: string record: TableRecordT old_record: null } type UpdatePayload { type: UPDATE table: string schema: string record: TableRecordT old_record: TableRecordT } type DeletePayload { type: DELETE table: string schema: string record: null old_record: TableRecordT }外部系统只需要处理一个端点通过type字段区分事件类型record是变更后的行old_record是变更前的行。INSERT时old_record为nullDELETE时record为null。验证确认请求已发出并收到响应pg_net 的机制决定了验证方式HTTP 请求在事务提交commit之后才开始执行等待执行的请求存放在net.http_request_queue表中执行后被删除响应默认在net._http_response表中保留6 小时。因此在目标表上执行一次真实的 INSERT / UPDATE / DELETE 并确认事务提交后在 SQL Editor 查询select * from net._http_response;关注status_code、content、error_msg和created列即可判断请求是否发出、外部系统返回了什么。_http_response表结构为id、status_code、content_type、headers、content、timed_out、error_msg、createdunlogged table。如果你知道某次请求的 ID直接调用net.http_post等函数会返回bigint类型的 request_id可以按 ID 精确查询select * from net._http_response where id request_id;request_id是占位符替换为函数实际返回的请求 ID。要批量查看失败请求select * from net._http_response where status_code 400 or error_msg is not null order by created desc;本地开发Webhook URL 的写法在本地 Supabase 实例上Postgres 运行在 Docker 容器里所以 Webhook URL 中的localhost或127.0.0.1指向的是容器本身而不是你运行应用的宿主机。要指向宿主机上的服务使用host.docker.internal如果不可用改用机器的本地 IP 地址。例如想让 Webhook 触发本地 Edge Function 时URL 写成http://host.docker.internal:54321/functions/v1/my-function-name如果在本地遇到 Webhook 连接问题先确认没有误用localhost。常见问题排查以下排查步骤来自 Webhook debugging guide。确认 pg_net 后台 worker 在运行Webhook 请求由 Postgres 的后台 worker 执行。先查它是否存活select pid from pg_stat_activity where backend_type ilike %pg_net%;如果没有返回整数值说明 worker 挂了。pg_net 0.8 及以上版本可以用这个函数重启 workerselect net.worker_restart();更早版本需要在 Dashboard 的 General Settings 里对实例做 fast reboot。请求超时超时问题在 pg_net v0.11 中修复对应 Postgres 15.6.1.135 及以上版本可在 General Settings 中升级 Postgres。文档给出的超时现象是_http_response中某条记录除id、error_msg、created外所有列都是 NULL。另外Webhook 默认每次执行队列中接下来的 200 个可用请求请求过密集时可能出现批量超时。可以在 Webhook Dashboard 中增大对应 Webhook 的 timeout 来缓解。其他两条注意不要在net._http_response或net.http_request_queue上添加触发器这些表比较特殊上面的触发器若失败或再次调用 pg_net 函数http_get、http_post、http_delete可能导致死循环。如果创建扩展相关操作报42501: permission denied for table http_request_queue按该排查文档处理先确认select * from net.http_request_queue为空然后尝试drop extension pg_net; create extension pg_net schema extensions;若因对象依赖等原因无法执行联系 Support。限制来自两份源文档的限制清单口径不同的地方已标注来源请求和响应存放在 unlogged tablesnet.http_request_queue、net._http_response中崩溃或非正常关闭时不保留。响应数据默认只保存 6 小时。pg_net 文档Limitations一节的口径只能发送带 JSON 数据的 POST 请求不支持 PATCH/PUT。而 Database Webhooks 文档的口径是 Webhook 可以以POST或GET发送 JSON payload——前者针对直接调用 pg_net后者针对通过 Dashboard 创建的 Webhook。配置上按最高 200 请求/秒设计提高速率可能引入不稳定pg_net 文档调试指南中的表述是默认执行队列中接下来的 200 个可用请求。只能同时工作在一个数据库上默认是postgres数据库。相关文档Database WebhooksWebhook 创建步骤、payload 结构与本地开发说明。pg_net: Async Networkinghttp_get/http_post/http_delete签名、响应分析、调试与配置。Webhook debugging guideworker 检查、超时与失败请求排查。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Supabase Database Webhooks 怎么在表格 INSERT、UPDATE、DELETE 事件上触发外部系统？
Supabase Database Webhooks 怎么在表格 INSERT、UPDATE、DELETE 事件上触发外部系统【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase你有一个具体任务当数据库里某张表发生行变更时自动通知一个外部系统——把新数据推送给外部 API、同步到其他服务或触发下游流程。Supabase 的 Database Webhooks 就是为此设计的你选定一张表和要挂钩的事件INSERT、UPDATE、DELETE中的一种或多种之后每当对应事件发生数据库就会向外发送一个带 JSON payload 的 HTTP 请求。所有事件都在数据库行变更之后触发。它的底层实现值得先了解Database Webhooks 是对 pg_net 扩展的触发器的封装。pg_net 是异步的因此长耗时的网络请求不会阻塞你的数据库写入。需要注意 pg_net API 目前处于 beta函数签名可能会变化。前提条件一个 Supabase 项目且目标表已存在于数据库例如publicschema 下的某张表。一个可访问的外部 HTTP 端点用于接收 Webhook 请求。通过 Dashboard 创建的 Webhook 可以以POST或GET发送 JSON payload。如果你选择 SQL 方式创建则直接使用 SQL Editor 执行触发器语句即可。方式一在 Dashboard 创建 Webhook主路径这是文档给出的最短路径在 Dashboard 的 Webhooks 页面创建一个新的 Database Webhook。为你的 Webhook 命名。选择要挂钩的表。勾选一个或多个要挂钩的事件表插入inserts、更新updates或删除deletes。由于 Webhook 本质上是数据库触发器同样一个 Webhook 也可以直接用 SQL 创建见下一节。方式二直接用 SQL 创建触发器Database Webhooks 文档给出的 SQL 示例create trigger my_webhook after insert on public.my_table for each row execute function supabase_functions.http_request( http://host.docker.internal:3000, POST, {Content-Type:application/json}, {}, 1000 );五个参数按示例依次为目标端点 URL、请求方法POST、请求头JSON 字符串、请求体JSON 字符串{}以及文档示例中的1000文档未解释该参数的含义照抄示例即可。示例中的表名my_table、URL 端口等替换为你自己的表和目标端点。上面的示例挂在after insert上。要响应UPDATE或DELETE把触发器条件换成after update或after delete——pg_net 文档中的触发器示例就展示了after update on table_name的写法。可选分支如果你不想用文档默认的 payload 结构而是自定义请求内容例如把old_row和new_row一起打包发送可以自己写一个返回trigger的函数并在其中调用net.http_postpg_net 文档的 Execute pg_net in a trigger 一节提供了完整示例。外部系统收到的 payload 结构payload 由底层表记录自动生成三种事件的结构如下源文档给出的 TypeScript 类型type InsertPayload { type: INSERT table: string schema: string record: TableRecordT old_record: null } type UpdatePayload { type: UPDATE table: string schema: string record: TableRecordT old_record: TableRecordT } type DeletePayload { type: DELETE table: string schema: string record: null old_record: TableRecordT }外部系统只需要处理一个端点通过type字段区分事件类型record是变更后的行old_record是变更前的行。INSERT时old_record为nullDELETE时record为null。验证确认请求已发出并收到响应pg_net 的机制决定了验证方式HTTP 请求在事务提交commit之后才开始执行等待执行的请求存放在net.http_request_queue表中执行后被删除响应默认在net._http_response表中保留6 小时。因此在目标表上执行一次真实的 INSERT / UPDATE / DELETE 并确认事务提交后在 SQL Editor 查询select * from net._http_response;关注status_code、content、error_msg和created列即可判断请求是否发出、外部系统返回了什么。_http_response表结构为id、status_code、content_type、headers、content、timed_out、error_msg、createdunlogged table。如果你知道某次请求的 ID直接调用net.http_post等函数会返回bigint类型的 request_id可以按 ID 精确查询select * from net._http_response where id request_id;request_id是占位符替换为函数实际返回的请求 ID。要批量查看失败请求select * from net._http_response where status_code 400 or error_msg is not null order by created desc;本地开发Webhook URL 的写法在本地 Supabase 实例上Postgres 运行在 Docker 容器里所以 Webhook URL 中的localhost或127.0.0.1指向的是容器本身而不是你运行应用的宿主机。要指向宿主机上的服务使用host.docker.internal如果不可用改用机器的本地 IP 地址。例如想让 Webhook 触发本地 Edge Function 时URL 写成http://host.docker.internal:54321/functions/v1/my-function-name如果在本地遇到 Webhook 连接问题先确认没有误用localhost。常见问题排查以下排查步骤来自 Webhook debugging guide。确认 pg_net 后台 worker 在运行Webhook 请求由 Postgres 的后台 worker 执行。先查它是否存活select pid from pg_stat_activity where backend_type ilike %pg_net%;如果没有返回整数值说明 worker 挂了。pg_net 0.8 及以上版本可以用这个函数重启 workerselect net.worker_restart();更早版本需要在 Dashboard 的 General Settings 里对实例做 fast reboot。请求超时超时问题在 pg_net v0.11 中修复对应 Postgres 15.6.1.135 及以上版本可在 General Settings 中升级 Postgres。文档给出的超时现象是_http_response中某条记录除id、error_msg、created外所有列都是 NULL。另外Webhook 默认每次执行队列中接下来的 200 个可用请求请求过密集时可能出现批量超时。可以在 Webhook Dashboard 中增大对应 Webhook 的 timeout 来缓解。其他两条注意不要在net._http_response或net.http_request_queue上添加触发器这些表比较特殊上面的触发器若失败或再次调用 pg_net 函数http_get、http_post、http_delete可能导致死循环。如果创建扩展相关操作报42501: permission denied for table http_request_queue按该排查文档处理先确认select * from net.http_request_queue为空然后尝试drop extension pg_net; create extension pg_net schema extensions;若因对象依赖等原因无法执行联系 Support。限制来自两份源文档的限制清单口径不同的地方已标注来源请求和响应存放在 unlogged tablesnet.http_request_queue、net._http_response中崩溃或非正常关闭时不保留。响应数据默认只保存 6 小时。pg_net 文档Limitations一节的口径只能发送带 JSON 数据的 POST 请求不支持 PATCH/PUT。而 Database Webhooks 文档的口径是 Webhook 可以以POST或GET发送 JSON payload——前者针对直接调用 pg_net后者针对通过 Dashboard 创建的 Webhook。配置上按最高 200 请求/秒设计提高速率可能引入不稳定pg_net 文档调试指南中的表述是默认执行队列中接下来的 200 个可用请求。只能同时工作在一个数据库上默认是postgres数据库。相关文档Database WebhooksWebhook 创建步骤、payload 结构与本地开发说明。pg_net: Async Networkinghttp_get/http_post/http_delete签名、响应分析、调试与配置。Webhook debugging guideworker 检查、超时与失败请求排查。【免费下载链接】supabaseThe Postgres development platform. Supabase gives you a dedicated Postgres database to build your web, mobile, and AI applications.项目地址: https://gitcode.com/GitHub_Trending/supa/supabase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考