Ensure deleting attributes takes place on the right connection#2264
Conversation
WalkthroughThe transaction management in the static deleting event of the Attribute model was refactored to use a specific database connection instance rather than the DB facade's static methods. The deletion and transaction operations are now performed through a connection object obtained via Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Note 🔌 MCP (Model Context Protocol) integration is now available in Early Access!Pro users can now connect to remote MCP servers under the Integrations page to get reviews and chat conversations that understand additional development context. ✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
packages/core/src/Models/Attribute.php (1)
46-49: Note: Transaction only covers pivot cleanup, not the Attribute deleteThis transaction commits before the model delete completes, so failures after this point can leave the Attribute row in place with pivots removed. If full atomicity is required, prefer DB-level FK cascades where possible or initiate a higher-level transaction around the delete operation.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/core/src/Models/Attribute.php(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (20)
- GitHub Check: PHP 8.4 - L^11.0 ↑
- GitHub Check: PHP 8.3 - L^11.0 ↑
- GitHub Check: PHP 8.3 - L^12.0 ↑
- GitHub Check: admin - PHP 8.4 - L12.* ↑ E
- GitHub Check: admin - PHP 8.4 - L12.* ↑
- GitHub Check: shipping - PHP 8.4 - L12.* ↑ E
- GitHub Check: search - PHP 8.3 - L12.* ↑ E
- GitHub Check: search - PHP 8.4 - L12.* ↑
- GitHub Check: stripe - PHP 8.4 - L11.* ↑
- GitHub Check: core - PHP 8.4 - L12.* ↑ E
- GitHub Check: admin - PHP 8.4 - L11.* ↑
- GitHub Check: core - PHP 8.3 - L12.* ↑ E
- GitHub Check: admin - PHP 8.4 - L11.* ↑ E
- GitHub Check: admin - PHP 8.3 - L11.* ↑ E
- GitHub Check: admin - PHP 8.3 - L12.* ↑
- GitHub Check: core - PHP 8.3 - L11.* ↑
- GitHub Check: admin - PHP 8.3 - L12.* ↑ E
- GitHub Check: stripe - PHP 8.3 - L11.* ↑ E
- GitHub Check: core - PHP 8.3 - L11.* ↑ E
- GitHub Check: admin - PHP 8.3 - L11.* ↑
🔇 Additional comments (1)
packages/core/src/Models/Attribute.php (1)
44-44: Lunar DB facade connection() already uses the Lunar-specific connection
Inspection ofpackages/core/src/Facades/DB.phpshows itsconnection()override callsparent::connection(config('lunar.database.connection'));so
DB::connection()without arguments resolves to the configured Lunar database. No code changes are required.
This PR fixes a bug where attributables deleting would take place on the default database connection, not the one specified for lunar.
Summary by CodeRabbit