轻松学会Laravel-项目篇(商城API) 45 订单过期_02 学习猿地原创

来这里写一下备注啊，定时检测。订单状态。嗯，超过十分钟。喂。支付的啊。啊，作废掉啊好。这里啊，那我们就在这里每分钟去检测查一下数据库，让它这个。未支付的作作废掉啊。看一看我们上面这个计划任务，每分钟输出这个哈，是不是已经有三分钟了，输出三个对不对啊，说明我们的计划任务是可行的啊。来接着就写我们的订单啊，但是我这里我给大家说一点啊，真正的这个啊，真实的项目中啊，真实的项目中基本不会这么做，因为他做不到一个实时性，比如你订单，你订单这个假如。

页面显示的是十分钟以后。啊，这个作废完订单就会失效，但是我们这个计划任务，你不可能说你刚好去赶到那个十分钟那里。啊，你计划任务你也是每分钟执行算，比如说你刚好你的频率是啊，每逢到30秒的时候，比如九分30秒执行啊，十分30秒执行，假如你十分30秒执行，那个订单已经超了这十分钟，是不是还会多了这个30秒，他不会那么精准。啊，不会这么做啊，呃，真实的项目一般处理这块怎么做呢？真实的项目啊，一般会使用长链接啊，就是当你去。创建了这个订单之后，他就给你的订单去建立了一个啊，相应的一个长链接啊，因为长链接我们可以做到实时的一个通讯，然后当你这个时间啊到了的话，直接就给你结束掉。

啊，时间到了。就是说到期了啊订单。过期了啊，直接作废。叫什么？啊，这个我们就啊，顺便刚好写到这一块了，然后把这个任务调度我们也学会去用一下。啊，任务调度就他可以让就是按照一定的时间就定时去帮我们去执行一些任务，比如说每周三的凌晨三点去备份数据库啥的是不是，比如说去，嗯清空一下日志表啥的是不是。都有可能啊。比如说嗯，总之根据你的业务需求去用就可以了。好吧。好，那这里我们就先这么写吧。首先要查出所有的未支付的订单。Order。

等于orders等于order。Where，未支付的订单是不是等于一的啊？来看一看我们的数据库的这个表结构。找到我们的order。这啊。看他的space思一是不是下单是不是，二是已经收了，三是发货四收货了对吧，所以一是应该是新下单的未支付的对吧。所以这里我们查这个stay等于一的，然后。并且是什么。时间是超了的是吧。是不是也就是在围绕这个。Corta。艾特。啊。算一下这个时间啊。这个时间啊，如果还在我们十分钟以内呢，我们就不用管它，但是它已经超过了这个十分钟。

哎，我们就要处理了。所以这个时间啊，要让它小于。谁呢？Time当前时间啊，减去，我们先写一分钟吧，一分钟方便我们测试。就是当前时间啊，减去一分钟。你如果创建时间还比他小的话，说明呃，已经在这个过去的一分钟以前的之前了，说不定已经超过了，就是过时了，一分钟多了是不是。所以这里我们把它转成。转成date啊，转成时间格式，让他去对比。好用这个时间啊。

然后get查询，查询所有的接着。循环订单。修改订单状态。然后。嗯，还有这个。还原。商品库存好，因为也涉及到一个多表，所以我们使用15啊。一个。E因为它是在这个后台运行的，所以这个拉的这个异常的话啊，我们就把它写到这个写到日志里面就可以了啊。应该是一个error。直接使用这个logo吧。logo的门面。

这个门面，然后使用它的这个error，把这个DOE写到日志里面就可以了，那我们来开启事物。D、闭门面。好，最后提交这个事物。然后当出现错误的时候。让事务回滚。哎，接下来就是开始循环我们的这个奥。然后修改它的状态线啊。它的等于。

啊。看一下啊，因为这里只有到四，我们再加一个五作废啊，就是过期的一个订单。过期的一个订单好。接着来写啊啊这个哈，就不让他，不让他执行了，不让他执行了。嗯。更新完订单的状态之后啊，要。还原商品库存，我们的订单详情里面就是它的所有的这个详情。看一下。啊，他的关联的所有的这个详情里面是关联的商品的一个数据，包括我们啊。商品的一个数量是不是。

拿到他所有的一个细节，哎，这时候其实还是需要去再便利一下啊，当然这种两层佛循环的去便利，肯定不是这么合适的。所以我们来改一下啊，不让它循环去查询，我们在这里查询的时候就把呃，相关的数据给带上。位子。这个啊。卡。它里面是不是还关联了这个。商品。他是不是还关联了商品看到了吗？啊，所以我们可以再继续第二这个商品，这样就能拿到。呃，关联的这个商品的一个数据，就不会说循环去查询数据库，而是一次性就把数据库给查出来，我们只是在循环数据而已啊，那接着。要干什么呢？把凹里面的。

Delicious啊，它这个啊，这是。这这个啊，它还是一个数组，所以我们要循环它，因为它有多个订单的一个详情。啊。好，它里面有一个一的商品叫什么。他商品的。库存等于谁，不是等于谁，我是要让他增加啊，所以可以调查模型的啊。Increment。让什么字段增加，让stock字段增加啊，增加谁呢？我们这个详情里面存的这个number，就是他购物的这个number，这样就可以了。是吧？啊，像这个自增，然后这是增量。啊，最后提交这样我们之前的这个就还原了。

嗯。我们做一个测试啊。怎么测试呢？你看我们现在是查的是这个一分钟是吧，减到60秒对不对。来，还拿我们这个订单表来测试。我先把这些全关了啊，看的有点多。打开订单表。啊，我们就看这个订单啊，用这个订单来进行测试啊。好。打开订单的详情。来五啊，这个订单ID是五，也就是我们最后一条五这一条，然后。这个详情它关联的商品是谁，是22，是不是我们来看22啊。22这条商品。再往下找，再找啊。22它的库存因为之前我们减过一次，剩575对不对，这里是减了多少，是购买了500，好，我们怎么鉴定呢？我们就看一分钟以后，我们这个500会不会还原回去。

然后我们这个订单的状态会不会变成。啊，不是，这已经变成五了。啊，已经已经变了，已经变了啊。嗯。是因为这些是已经过期的订单了，因为一直没有支付嘛。啊，但是他没有变啊。所以我们来做一个呃测试，要把数据先给还原回来啊。怎么还原呢？先把它改成一，那第一个过期了，我们就不管了，先把它改成一，然后时间改成现在的时间。因为现在的时间的话，它是没有过期的是不是。对不对，现在是。啊，时间我超前一点也行。嗯，这里改成。

看一下他这个时间啊。我的时间改一改啊，创建时间。改成46吧，就改成46，因为这个时间也马上快跳46了，改成四十六零零。回撤来更新一下。然后这个状态也得更新成一。啊。一然后是46创建的刚好时间46，我们就见证一分钟以后啊，它的这个状态会不会变成五，而且商品的这个数量啊，会不会还原，就可以证明我们这个计划任务的代码写的有没有问题清楚吧。啊。来，当然同时也可以干什么呢去？

把这个日志文件先删掉，看他会不会生成。新的错误日志啊。如果就是说我们这里你看代码的执行出错的话，有问题的话，这里会给我们生成一个就是说写入的一个日志错误。好。再来看一下这个代码，应该是没有问题，循环订单，然后把订单的状态修改之后，从订单里面拿订单的详情，把订单详情所关联的商品。叫做就是说啊，它的库存进行一个增加。是不是？好，47了。那这个时间我来刷新一下。是不是已经变了？啊，更新时间也变了，更新时间是四十七零二的时候更新的，它的状态变了，那我们看商品的数量有没有还原回来。是不是回来了，哎，说明我们这个。计划中是可行的啊，当然那我们就把这个给改一改啊，改成正常的这个十分钟嘛，啊改成600。

可以吧，好。嗯。那你们可能感觉，哎，我这里要先拿。详情，再从详情里面去拿商品是不是比较麻烦，那有没有简单的方法？我告诉你们还真有啊，是因为我们这个详情，你看我们订单和详情有关联，是不是，详情又和谁呢？和商品有关联对不对，所以详情可以是作为他俩的一个中间表。哎，比如说你关联到他，他关联到它，所以详情是不是可以作为一个中间表啊，这时候我们可以使用什么，使用模型的远程啊，远程一对多，因为商一个订单的话，它是有多个这个详情，那对应的就会有多个商品。所以使用远程一对多的形式就可以啊，我们来看看怎么配。嗯。找到模型，模型关联这里。找到远程的这个。不是多彩，是远程一对多啊，然后。

使用这个has many。配到我们的。订单表里面来，我们配一下。找到订单的这个模型。Model。来在这里我们写一个这个啊。方法改了，改成商品，也就是订单啊，关联的远程的商品。订单。远程一对多。啊，关联的商品，接着把这些改一改，这个是。啊，我们要最终。要拿到这个数据是不是商品啊，所以是商品的这个类名class啊，类名这个是中间表，也就是说哎，我们这个表是和谁有关系，是不是和他有关系，他才又有商品有关系，所以这是中间表啊。

也就是他。Class。啊，接着啊。这是什么？外见啊。也就是我们这个表的。这个这个外键。清楚吧。啊，就是我们这个就是他。就是我们这个表，Order表和它是用什么键关联的，是不是它里面的这个order ID。啊。这个是对应的组件，也就是我们订单表的ID啊，订单表的ID是和订单详情的这个auto-ID进行关联的啊，这是一对。接着啊。这个啊，这个是。啊，我们本表订单的这个order这个ID嘛，这个是关联表的中间表的这个关联的一个ID，那它呢，它是我们最终关联的这个表的它的一个ID啊，也就是对于中间表而言，它的一个外键。

你看是不是中间表的。固执杠ID和他的ID关联，对这个就是啊。这个就是它的这个ID，那第四个就是你看第二个本地的一个键，它是不是作为第二个这个中间表，它的本地的一个和它关联的键，是不是故障D和它进行关联呢。是不是这么关联的啊，把那个注释都改一改啊，这个是最终关联的模型啊，这个是我们中间表中间模型啊。那这个是就说本表本模型。就是中间模型啊。和本模型关联的键。

啊，过年再见。对不对。就是中间模型的它的这个外键和本模型的一个关联的一个键啊。好。那对应的它是一对，这个是，嗯。本模型。也就是。这个是本模型啊和中间模型。关联的。按这个键。知道吧，注意这个是反着写的，这是中间模型和我们这个本表凹表关联的一个外键。啊，关联的这个外键。然后这个是我们本模型和中间模型关联的一个组件啊，一个组件，本表的一个组件。那这个就是最终表的。

最终关联模型的。啊，这个键啊，外键啊。就是相对于中间表来讲，这个它啊。就是它的一个相当于它的一个从表，所以用的是它的最终模型的一个关键关键，而这个是中间表的啊，中间表和最终模型。关联的啊，一个键啊。一个键组件就是看谁是主表的从表，如果我们把它作为主表，它是从表而言的话，这个是相当于主表，你看主表的组件嘛，是不是它。是不是这个是最终模型表，它的表的一个从外间嘛，外间是不是它的这个ID，你这么去理解。就是谁，谁和谁是谁是主次的一个关系。好，首先比较绕啊，那定义完这个之后呢，我们使用的时候就比较简单了，就可以直接。

啊，在这个里面。就不用这么绕了，就可以直接拿它下面的这个商品。清楚吧。拿它下面的商品，然后as do goods商品，然后直接让这个商品的这个数量去。增加就可以了。当然。呃，还是得用到这个数量啊，所以。我们还是这么写就行啊，这么写就行，因为确实要用到它这里面的一个数量。所以我们这个配的这个一对多暂时用不着，但是以后会中多少，比如我们看订单详情的时候，订单详情我们比如查订单详情，那你不可能说你先查关联表，然后再从关联表里面查商品。是不是是不是可以直接从。我们这个远程一对都要去从拿到这个商品的一个数据。再来看看这个啊，这个少撤回了一个。

啊。啊，当然你直接用这个也是可以的啊，直接用这个，只不过你要再去多处理一下，从细节里面去拿那个数量进行数量的一个返回。是吧？啊，这样的话，我们订单就算优化完了啊，包括。呃，就是库对库存的一些限制，一些处理。啊，都做了一个优化。这样我们的API就会，嗯，稍微健壮一些，不会出现一些流程上的一些呃，Bug。啊，当然这么写只是临时的去写一下啊，真正的其实在我们的项目中很少这么去去做啊，很少我们去做。一般会使用其他的一些方案。最后呢，既然这个一对多配置完成了，我们总来看一下效果吧，是不是来找个地方测试一下啊。找个。控制器。好啊，就拿生成订单的这个吧。啊，因为这个传一个D宅D可以我们在这里进行测试，好，那这里。

测试一下这个。远程。一对多啊。首先我得查一个凹的。等于order。饭直接去表里面拿ID。就拿第五条这个吧。或者拿第四条这个吧。好，接着。啊，商品我就直接等于什么呢，Order里面的裤子。对吧，因为你看这个order的这个故子，这个关联关系，它是不是一个一对多的关系，我们看能不能直接拿到。这个。商品的数据，就是直接跳过中间表去拿到商品的一个数据啊，来直接进行一个测试啊。嗯，在这里面请求。

啊，这个就是我们创建订单的，是不是来直接发起请求。啊，Talking过期再去生成一个。来发起请求。看一下。你看是不是。拿到了我们这个商品的数据，你看商品。看到了吗？这是订单关联的两个商品吗？因为我们这里返回的就是你看的就是这个商品嘛。是这样吗？啊，当然你也可以比如说啊，Where。ID等于这个四的，然后使用这个位置去关联上这个商品的数据也行啊，看看看看啊。那我现在就直接返回这个order吧。返回这个订单来检查一下请求。

可以看到这些是我们订单的这个数据，是不是，然后给我们带着这个商品的数据，没有走中间表吧，没有走那个订单的详情。啊，这个就是我们的远程一对多啊，当有这个啊中间表存在的时候，可以用远程一对多去啊，绕过这个中间表直接去拿，最终我们要关联的这个模型好好理解一下还是比较好用的。啊，当然我这么简单的注释。简单的写的这些注释不太好理解的话，你去，呃，再去看一看手册介绍这个例子也比较详细啊。好，关于订单这块就说到这里，在后面我们就会基于这个订单去完成这个支付的一些相关的一些功能。