Fix extended model resolving

[alecritson]

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

\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:

\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.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
lunar-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 17, 2024 8:34am

[ken717w]

Can't wait to see the next beta version 👍🏻. So far most of the issues I encountered are related to model extending.