手机浏览 RSS 2.0 订阅 膘叔的简单人生 , 腾讯云RDS购买 | 超便宜的Vultr , 注册 | 登陆
浏览模式: 标准 | 列表分类:PHP

折腾,为 lnmp 的套件增加 readline 扩展

lnmp.org 的工具还是相对比较好用的,可以根据情况进行安装。一般默认采用./install.sh lnmp 就完事了,当然也可以单独安装,例如:./install.sh nginx

但现在这个工具安装好后,默认是没有 php -a 的功能,运行 php -a 会提示,这需要 readline 扩展(PHP8 才会有这个问题)
 
由于我用的 debian,开始的时候,我是改他的脚本,但最后 php -m|grep readline 的时候还是没有安装成功。查看出错日志,说是找不到 readline 和 libedit 的扩展,所以只能先 apt install readline-dev libedit-dev,安装完这两个包后,回到 lnmp 的目录下,进行 src 目录。tar xvf php{version}的 tar.bz2。然后到 ext 目录下,找到 readline 目录
 
进入目录后就是标准的 PHP 扩展编译了:phpize ,然后./configure --with-php-config=/usr/local/php/bin/php-config,然后 make && make install
最后再到 /usr/local/php/conf.d 建一个 ini 文件,里面就一句话:extension="readline.so"
 
然后就可以 php -a 了。
之所以要 readline,是因为在服务器上 php artisan tinker 后,光标无法返回,点击方向键出来的都是键位码,实在不方便操作。
---EOF
PS:5 月份居然一篇没写?这不科学 

filamentphp 在 cloudflare 背后还是有不少问题的

 如果想偷懒用 cloudflare 的 https 来做为网站的 https,这时候你的后台或者你的网站采用了 livewire/filamentphp,那么问题还是不少的

 
1、极有可能你会出现部分 js,加载的时候还是 http,这时候要做两步处理:强制 schema 为 https,还有就是增加 ASSET_URL 为你的 https 的域名
2、上传文件时,可能会遇到 401,这是因为从 cf 过来。就是在代理后面,你可以在 middleware 中增加:$middleware->trustProxies(at: '*');
 
这两个都是大问题,而且平时还看不太出,开发的时候也不会遇到,只有在部署上线的时候才会有这样的问题
 

数据恢复时丢失索引。

 为了快速恢复数据,选择了没有外键之类的。结果导致所有的主键丢失、外键丢失(外键是我自己选择不要的,因为写 PHP 的代码的早期,全是靠程序来处理外键。很少用 foreign-key 的)。

但主键没有确实有点意外,不过还好。数据表不多,加起来就行了
 
---
等会去看一下 DDL 相关,是不是我在复制和恢复的时候没有主动打勾。但数据已经加了两条我就先不管其他的了(只是做一下操作看看原因。)
 
----
 
确实是操作失误,在迁移数据的时候选择了 data only,忽略了数据库结构。所以要这样做
1、先复制 DDL,创建完表
2、再 COPY 数据,DATA ONLY。这样就 OK 了
3、

数据又丢了一次

这次的丢数据确实挺意外。

我是在执行 migrate 的时候。他居然直接清空了所有的表。所以这个还是要慎重(原来的项目是 sablog ,新项目用 laravel 来管理的时候,因为没有 migration 文件,他居然先 truncate table 了),这个很纠结。
 
还好,我用的是腾讯云的轻量云。他可以按时间点恢复备份。还好我最后一篇是 13 号的,所以我恢复到了 14 号的数据。基本上算丢失一天的内容(其实也只有评论了)。
后续对这些数据我还是要考虑一下如何备份,因为平时默认我没有备份数据库的习惯。
 
顺便说一下,轻量数据库还是挺合算的费用不高,还有这么多功能,比直接自己本地装一个 mysql 合适多了。
 

Laravel 的 chunk 和 chunkId 丢数据的问题

 用 Laravel 处理大量数据时,如果不用 chunk 基本上就是卡成狗,毕竟你不可能在数万条、数十万条数据,光是请求回来都要花很长时间 ,因此,chunk 100 条或者 50 条,反而是效果更高

网上的一些例子都是建议 chunk,而不是 chunkById。但事实上你使用 chunk 的时候,也需要 orderby 一下,否则你也不清楚你的 where 条件出来的数据会是怎样的排序。而且 chunk 还有个问题就是你的每次更新其实不是实时的,当你在处理下一个 chunk 的时候,你可能还在 update 上一个 chunk 的数据。
 
经过测试 20000 条数据处理,order by id ,再 chunk(100),数据处理的时候会断开【即:处理到 10000 条左右的时候 就结束了,没有任何报错。】,然后再执行,就剩 5000 条左右,再执行剩 2500 左右。
测试用 chunkById,chunk(100),一次就全部处理完后,就没有丢过数据,其实看代码也能够比较明显的,其实 chunkById 才应该是我们的正常用法,因为他会获取上次取完的最后一条 ID,再处理 $count 的值。
 
---EOF
Records:64912345678910»