分类： Laravel
-
本文针对 Laravel 6 中跨多个 MySQL 数据库连接使用事务的问题进行探讨。在涉及数据库 A 和数据库 B 的跨库写入场景下，现有的仅对单库使用事务会导致脏数据问题。文章通过模型配置连接，参考社区方案对两个连接同时开启事务，并测试了不同阶段的插入失败情形。测试结果显示，在多数异常情况下事务均能正常回滚，确保数据一致性，但对于双重提交时的潜在异常处理仍留待后续分析。
-
本文探讨了在 Laravel 6 的 Eloquent ORM 中使用数据库事务的方法。鉴于应用运行于 PHP 7.0 及更高版本，代码中将捕获对象从 \Exception 替换为 \Throwable。文章展示了最终的实现代码，并通过测试验证了事务机制：故意构造失败场景时，事务成功回滚，确保三张表中均未插入数据；而在事务成功执行后，确认三张表的数据均已正确写入。
-
Laravel 6 的数据库迁移默认不支持直接添加表注释，参考相关解决方案后，通过修改迁移代码实现了这一功能。执行数据库迁移并查看结果，确认表注释已成功添加到数据表中。
-
文章针对Laravel 6中间件中无法通过点击跳转方法的问题，分析了原有基于app函数实现的局限性。通过参考服务容器的自动注入机制，演示了如何在中间件构造函数中使用类型提示注入依赖项。重构后的代码不仅符合Laravel对象解析的规范，还成功实现了IDE中从getByName()方法直接跳转至对应定义的功能。
-
在解决 Lighthouse 开发中的 BindingResolutionException 报错时，排查发现是目标类无法实例化。通过 php artisan module:list 确认 ThemeStore 模块状态正常，启用模块后错误依旧。最终检查配置文件，发现 config/app.php 的 providers 中 ThemeStoreServiceProvider 类被注释。取消注释该服务提供者类后，问题解决，不再报错。
-
文章记录了在 Laravel 6 和 Lighthouse 环境中遇到 TypeRegistry::get() 参数类型错误，经排查发现是 GraphQL 类型定义与实际代码实现不符，通过打印参数值定位到 settings 字段问题，并将 theme_setting.graphql 中的类型定义从 [ThemeSetting!]! 修改为 [ThemeStyleSetting!]!，最终解决了报错并使接口正常返回。
-
在 Laravel 6 和 Lighthouse 5 环境下，使用 @rules 指令应用 exists 验证规则时，自定义属性名无法按语言区域正确翻译，导致返回的验证消息中包含原始字段名而非本地化名称。经过排查，排除了 nwidart/laravel-modules 版本及语言文件位置的影响，确认原因在于 Lighthouse 5 对验证属性的支持不够彻底。目前决定暂不编写自定义验证器类，暂时接受在非英语环境下属性名未被完全翻译的现状。
-
针对在 Laravel 6、LightHouse 5 和 PHPUnit 环境中编写 Mutation 测试时需要删除缓存数据的需求，文章参考了 REST API 测试中先操作数据库再请求删除的思路。通过调整测试策略，先直接操作缓存生成明确的缓存标识，随后执行 HTTP API 请求进行删除操作。实际运行结果显示，该方案成功通过测试，实现了对删除缓存标识 Mutation 的有效验证。
-
本文介绍了在 Laravel 6 结合 Lighthouse 5 及模块化架构下，为 GraphQL API 创建自定义验证规则的过程。通过在模块中生成规则类，编写逻辑判断缓存标识是否存在，并在 Schema 文件中使用 @rules 指令引用该规则，实现了验证逻辑的复用。文章还详细说明了如何配置模块内的多语言文件以返回本地化错误消息，最终完成了包含中英文错误提示的接口功能测试。