Unable to create order #1930
Comments
|
public function boot(): void |
|
@infinitodk can you try if it fixes your issues as well? "require": {
"lunarphp/lunar": "dev-update-container-resolution as 1.0.0-beta.1",
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/theimerj/lunar.git"
}
] |
|
Will try, came to the same conclusion as you, that a serialization happened to early. I also noticed that it references the classes wrong in polymorphic relationships aswell. |
You are right, addressed by this commit: edb019f |
|
I have the same problem and installing your repository indeed solves the problem for now. |
|
We have a patch #1944 which should solve this issue in the next release 🤞 |
|
Unfortunatelly this does not solve all the problems introduced with the updated model extending as shown here: theimerj#2. I made a branch out of |
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 <[email protected]>
Expected Behaviour:
Creating order from basket should work
Actual Behaviour:
Getting Shipping breakdown must be instance of Lunar\Base\ValueObjects\Cart\ShippingBreakdown.
Works in previously versions.
Steps To Reproduce:
// Create a new cart for the user
$cart = Cart::create([
'currency_id' => Currency::first()->id,
'channel_id' => Channel::first()->id,
'user_id' => $user->id,
]);
The text was updated successfully, but these errors were encountered: