Cannot update meta of existing OrderLine instance
#1942
Comments
|
Isn't this a duplicate or at least a relation of #1939 ? |
I'm not 100% sure because in my case I've extended |
That makes sense because the 'default' (Laravel) way right now is the actual class name so in this case Lunar\Models\ProductVariant |
|
Hey @ken717w, can you try by installing this version? "require": {
"lunarphp/lunar": "dev-update-container-resolution as 1.0.0-beta.1",
},
"repositories": [
{
"type": "vcs",
"url": "https://github.com/theimerj/lunar.git"
}
]That directly corelated to #1933 which will hopefully fix most of the problems with extending. |
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]>
|
#1949 doesn't seem to have fixed this issue. I can only get it to work by setting to |
fixes #1942 fix `class_implements` error on string 'product_variant' Co-authored-by: Alec Ritson <[email protected]>
Expected Behaviour:
Successfully save the updated meta data to database.
Actual Behaviour:
Gets error "class_implements(): Class product_variant does not exist and could not be loaded".
Steps To Reproduce:
When creating the order line object, I followed the docs and set
purchasable_typetoproduct_variant.Currently my workaround to make it works is to set
purchasable_typeto either\Lunar\Models\ProductVariant::classorget_class($variant).The text was updated successfully, but these errors were encountered: