首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

正在使用Postgres更新...不带原始SQL的Ecto中的FROM

在Ecto中,更新Postgres数据库记录时,可以使用Ecto.Query.from/2函数指定要更新的表。然而,Ecto不支持直接在更新查询中使用FROM子句。相反,我们可以使用Ecto.Query.join/5函数来模拟FROM子句的功能。

下面是一个示例代码,演示如何在Ecto中更新Postgres数据库记录,而不使用原始SQL并模拟FROM子句:

代码语言:elixir
复制
query =
  from p in Post,
  join: u in User, on: p.user_id == u.id,
  where: u.name == "John",
  update: [set: [title: "New Title"]]

Repo.update_all(query, [])

上述代码中,我们首先使用Ecto.Query.from/2函数指定要更新的表为Post。然后,使用Ecto.Query.join/5函数将Post表与User表进行连接,并指定连接条件为p.user_id == u.id。接下来,我们使用Ecto.Query.where/3函数指定过滤条件,即u.name == "John",以便只更新用户名为"John"的记录。最后,我们使用Ecto.Query.update/2函数指定要更新的字段和新的值,即[set: [title: "New Title"]]

最后,我们使用Repo.update_all/2函数执行更新操作。第一个参数是查询语句,第二个参数是查询参数,这里我们传递一个空列表[]作为参数。

这样,我们就可以在Ecto中更新Postgres数据库记录,而不使用原始SQL并模拟FROM子句。

推荐的腾讯云相关产品:腾讯云数据库PostgreSQL

腾讯云数据库PostgreSQL是腾讯云提供的一种高度可扩展、高性能、高可靠性的关系型数据库服务。它基于开源的PostgreSQL数据库引擎,并在此基础上进行了优化和增强,提供了丰富的功能和工具,以满足各种应用场景的需求。

产品介绍链接地址:https://cloud.tencent.com/product/postgres

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • postgresql 触发器 简介(转)

    – 把before for each row的触发器删掉, 再测试插入 : postgres=# drop trigger tg02 on t_ret; DROP TRIGGER postgres=# drop trigger tg2 on t_ret; DROP TRIGGER postgres=# insert into t_ret values(1,’digoal’,now()); NOTICE: 00000: tg01 LOCATION: exec_stmt_raise, pl_exec.c:2840 NOTICE: 00000: tg1 LOCATION: exec_stmt_raise, pl_exec.c:2840 NOTICE: 00000: tg03, after for each row 的触发器函数返回空, 不影响后续的触发器是否被调用. 因为只要表上面发生了真正的行操作, after for each row就会被触发, 除非when条件不满足. (这个后面会讲到) LOCATION: exec_stmt_raise, pl_exec.c:2840 NOTICE: 00000: tg3 LOCATION: exec_stmt_raise, pl_exec.c:2840 NOTICE: 00000: tg04 LOCATION: exec_stmt_raise, pl_exec.c:2840 NOTICE: 00000: tg4 LOCATION: exec_stmt_raise, pl_exec.c:2840 INSERT 0 1 – 有数据插入. 这也说明了before for each statement的返回值为空并不会影响数据库对行的操作. 只有before for each row的返回值会影响数据库对行的操作. postgres=# select * from t_ret ; id | info | crt_time —-+——–+—————————- 1 | digoal | 2013-03-10 16:50:39.551481 (1 row)

    02

    PostgreSQL 使用advisory lock或skip locked消除行锁冲突, 提高几十倍并发更新效率

    背景 通常在数据库中最小粒度的锁是行锁,当一个事务正在更新某条记录时,另一个事务如果要更新同一条记录(或者申请这一条记录的锁),则必须等待锁释放。 通常持锁的时间需要保持到事务结束,也就是说,如果一个长事务持有了某条记录的锁,其他会话要持有这条记录的锁,可能要等很久。 如果某张表的全表或者大部分记录要被更新的话,有几种做法。 1. 在一个事务中更新需要更新的记录,很显然时间可能很长,因为没有了并发。 2. 在多个事务中更新不同的记录,使用高并发来缩短更新的时间,但是就需要解决并发更新时存在的行锁冲突的问题。

    06

    基于Apache Hudi和Debezium构建CDC入湖管道

    当想要对来自事务数据库(如 Postgres 或 MySQL)的数据执行分析时,通常需要通过称为更改数据捕获[4] CDC的过程将此数据引入数据仓库或数据湖等 OLAP 系统。Debezium 是一种流行的工具,它使 CDC 变得简单,其提供了一种通过读取更改日志[5]来捕获数据库中行级更改的方法,通过这种方式 Debezium 可以避免增加数据库上的 CPU 负载,并确保捕获包括删除在内的所有变更。现在 Apache Hudi[6] 提供了 Debezium 源连接器,CDC 引入数据湖比以往任何时候都更容易,因为它具有一些独特的差异化功能[7]。Hudi 可在数据湖上实现高效的更新、合并和删除事务。Hudi 独特地提供了 Merge-On-Read[8] 写入器,与使用 Spark 或 Flink 的典型数据湖写入器相比,该写入器可以显着降低摄取延迟[9]。最后,Apache Hudi 提供增量查询[10],因此在从数据库中捕获更改后可以在所有后续 ETL 管道中以增量方式处理这些更改下游。

    02

    干货|分析PostgreSql单表60w数据却占用55g空间

    突然听到运维说磁盘预发布环境磁盘空间不够,细查之下发现是由于某个表的数据太大导致的,但是查看了下数据库表发现,实际的表数据量只有60w条,很明显表哪里出问题了,一开始以为是犹豫表的设计不合理索引导致的数据量大,细看之下发现挺正常的。正在焦虑蹉跎的时候,有幸得到朋友圈大佬的指点,是死亡元组太多导致的只需要执行vacuum full清理死亡元组就好,查看了相关的博客稳定发现postgresql居然会保存mvcc多版本修改记录,简单理解就是,postgresql对你所做的修改和删除都会保存记录,不会清理释放空间。这让我顿时想到[Mysql的MVCC],但是mysql的undo log也只记录执行操作的相反记录保留最新的记录,而redo log记录数据页的变更,但是大小是固定的,都可以通过配置参数配置固定大小。

    05
    领券