Laravel 5.3 查询构建器方法 where/update 新增 JSON 属性操作语法

从 5.0 版本起 Laravel 就支持 JSON 格式数据的转换,之前这样做的目的只是为了方便业务处理,数据存储在数据库的数据类型依然是 TEXT,但是 MySQL 5.7 版本起开始支持原生的 JSON 数据类型,这将为我们的开发带来极大方便。Laravel 5.3 也为基于 JSON 类型的数据查询和更新引入了新的语法。

假设我们有一个包含 JSON 类型字段的数据表:

class CreateContactsTable extends Migration
{
    public function up()
    {
        Schema::create('contacts', function (Blueprint $table) {
            $table->increments('id');
            $table->string('name');
            $table->json('meta');
            $table->timestamps();
        });
    }
    ...
}
我们假设每个联系表单都包含一些基本功能信息,比如联系人姓名,但是另外的一些属性是很灵活的,存储这种类型信息的最好方式就是 JSON 类型 —— 就像上面的 meta 字段。

假定某个联系表单信息如下:

{
    "id": 1,
    "name": "Alphonse",
    "meta": {
        "wants_newsletter": true,
        "favorite_color": "red"
    }
}
现在我们想要获取所有favorite_color为red的用户,在 Laravel 5.3 中我们可以这么做:

$redLovers = DB::table('contacts')
    ->where('meta->favorite_color', 'red')
    ->get();
这段代码将会从contacts表中把meta字段的favorite_color属性值为red的所有记录取出来。

如果想要更新meta字段属性可以这么做:

DB::table('contacts')
    ->where('id', 1)
    ->update(['meta->wants_newsletter' => false]);
即使wants_newsletter键值之前为空,现在也会被设置为false。

神奇吧,在 Laravel 5.3 中我们可以基于JSON字段的属性进行查询和更新,而不需要去写那些枯燥重复的处理代码。

注:目前只有 MySQL 5.7+ 支持这一特性。

时间: 2024-09-12 22:03:26

Laravel 5.3 查询构建器方法 where/update 新增 JSON 属性操作语法的相关文章

Laravel查询构建器对数据库增删改查的例子

获取查询构建器很简单,还是要依赖DB门面,我们使用DB门面的table方法,传入表名,即可获取该表的查询构建器: $users = DB::table('users'); 这样我们就获取到了$users表的查询构建器,实际上,底层返回的是Illuminate\Database\Query\Builder的实例,我们对查询构建器的所有操作都是调用该实例对应类上的方法.下面我们就列举查询构建器的一些常用方法,我们还是沿用上一节创建的$users表做演示说明 . 1.新增数据 使用查询构建器的inse

Laravel使用查询构建器实现对数据库(分组 联合 分页 排序)

1.连接查询(join) 连接查询指的是将两张表或多张表关联到一起进行查询,获取一个表的行与另一个表的行匹配的数据.常见的连接查询包括内连接(等值连接).左(外)连接.右(外)连接和交叉连接(完全连接)等.下面这张图形象的展示了这几种连接查询所获取的结果集: SQL连接查询 下面我们简单演示下内连接和左连接.我们将用户表users和文章表posts关联到一起进行查询,在此之前,我们先创建posts表,其字段及初始值如下: 文章表posts 其中user_id对应users表中的用户id. 1.1

定义查询构建器IFeatureLayerDefinition

在宗地出图,需要实现,只显示某一户人的地块.在ArcMap里,有个定义查询,可只显示过滤后的要素. 在代码中,也比较好实现,使用IFeatureLayerDefinition接口即可. IFeatureLayerDefinition pFeatLyrDef = pFeatureLayer as IFeatureLayerDefinition; pFeatLyrDef.DefinitionExpression = whereClause; axMap.ActiveView.Refresh();

构建器内部的多形性方法的行为

构建器调用的分级结构(顺序)为我们带来了一个有趣的问题,或者说让我们进入了一种进退两难的局面.若当前位于一个构建器的内部,同时调用准备构建的那个对象的一个动态绑定方法,那么会出现什么情况呢?在原始的方法内部,我们完全可以想象会发生什么--动态绑定的调用会在运行期间进行解析,因为对象不知道它到底从属于方法所在的那个类,还是从属于从它衍生出来的某些类.为保持一致性,大家也许会认为这应该在构建器内部发生. 但实际情况并非完全如此.若调用构建器内部一个动态绑定的方法,会使用那个方法被覆盖的定义.然而,产

Laravel使用Caching缓存数据减轻数据库查询压力的方法_php实例

本文实例讲述了Laravel使用Caching缓存数据减轻数据库查询压力的方法.分享给大家供大家参考,具体如下: 昨天想把自己博客的首页做一下缓存,达到类似于生成静态页缓存的效果,在群里问了大家怎么做缓存,都挺忙的没多少回复,我就自己去看了看文档,发现了Caching这个部分,其实之前也有印象,但是没具体接触过,顾名思义,就是缓存了,那肯定和我的需求有点联系,我就认真看了看,发现的确是太强大了,经过很简单的几个步骤,我就改装好了首页,用firebug测试了一下,提高了几十毫秒解析时间,当然了有人

详解SQLite中的查询规划器_数据库其它

 1.0 介绍 查询规划器的任务是找到最好的算法或者说"查询计划"来完成一条SQL语句.早在SQLite 3.8.0版本,查询规划器的组成部分已经被重写使它可以运行更快并且生成更好的查询计划.这种重写被称作"下一代查询规划器"或者"NGQP". 这篇文章重新概括了查询规划的重要性,提出来一些查询规划固有的问题,并且概括了NGQP是如何解决这些问题. 我们知道的是,NGQP(下一代查询规划器)几乎总是比旧版本的查询规划器好.然而,也许有的应用程序在

Effective Java (2) 遇到多个构造器参数时要考虑用构建器

一.背景 对于有多个可选参数的类,我们一般通过什么办法传递参数呢?这里提供了三种办法: ①. 重叠构造器模式 ②. JavaBeans模式 ③. Builder构建器模式 下面我们来分析一下以上三种方法的优势及弊端. 二.重叠构造器模式 重叠构造器模式中第一个构造器中只有必要参数,第二个构造器有一个可选参数,第三个构造器中有两个可选参数,依次类推,最后一个构造器中包含所有可选参数.这种方案可行,但是有较大缺陷. 缺点:当有很多可选参数的时候,客户端代码很难编写,并难以阅读,如果客户端不小心颠倒了

副本构建器

克隆看起来要求进行非常复杂的设置,似乎还该有另一种替代方案.一个办法是制作特殊的构建器,令其负责复制一个对象.在C++中,这叫作"副本构建器".刚开始的时候,这好象是一种非常显然的解决方案(如果你是C++程序员,这个方法就更显亲切).下面是一个实际的例子:   //: CopyConstructor.java // A constructor for copying an object // of the same type, as an attempt to create // a

构建器

为违例编写代码时,我们经常要解决的一个问题是:"一旦产生违例,会正确地进行清除吗?"大多数时候都会非常安全,但在构建器中却是一个大问题.构建器将对象置于一个安全的起始状态,但它可能执行一些操作--如打开一个文件.除非用户完成对象的使用,并调用一个特殊的清除方法,否则那些操作不会得到正确的清除.若从一个构建器内部"掷"出一个违例,这些清除行为也可能不会正确地发生.所有这些都意味着在编写构建器时,我们必须特别加以留意. 由于前面刚学了finally,所以大家可能认为它是