Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix extended model resolving (#1949)
This PR looks to solve some anomalies that have been discovered with model extending. ## Problem A When replacing a Lunar model, there are instances where the model provided by Lunar is still used for example, if you replace the model like so ```php \Lunar\Facades\ModelManifest::replace( \Lunar\Models\Contracts\Order::class, \App\Models\Order::class ); ``` Later in the Lunar core, we are still referencing `Lunar\Models\Order::first()` or via relationships `$orderLine->order()`. We attempted to resolve these queries to their concrete replacements by overriding the `newModelQuery` method, however there were issues with castable attributes which caused them to be cast multiple times, resulting in errors. ### Solution This has been rewritten so Lunar doesn't try to `fill` the extended instance of the model from the Lunar base class anymore and instead just populates the attributes as they are. Since this should just be a simple class swap it should no longer result in duplicate calls to attribute casters. There are some additional checks to see if we are actually working with a model that hasn't been extended to ensure we are not getting into a situation where we try and rehydrate with the same class. ### Affected issues This change should resolve #1942 #1930 ## Problem B If your own custom model was named something other than it's counterpart, for example: ```php \Lunar\Facades\ModelManifest::replace( \Lunar\Models\Contracts\Order::class, \App\Models\MyCustomOrder::class ); ``` This would result in the table name and subsequent foreign key naming to be incorrect i.e. `my_custom_order` and `my_custom_order_id`. This would mean developers would need to add their own methods to override this in order for the naming to resolve properly, which is a bit of a maintenance burden and easily missed when encountering errors. ### Solution The `HasModelExtending` trait now provides its own `getTable` and `getForeignKey` methods which will check which class within Lunar we are extending and return the appropriate table name and foreign key. ## How this slipped through testing Looks like there was an oversight and although there were tests for extending models, the tests themselves didn't use any extending when performing more complex tasks, like creating orders from carts. This PR has now added some model extending to tests which were affected by the issues referenced above to hopefully keep this in check and make for a more "real world" test environment. --------- Co-authored-by: alecritson <alecritson@users.noreply.github.com>
- Loading branch information