I am trying to extend the ShoppingList-entity with a custom property business unit owner (buOwner). Using the SerialFieldExtensionBundle works fine with migrations (in backend admin panel > manage entities a custom column appers as a serial type property). https://github.com/oroinc/OroEntitySerializedFieldsBundle
1. Created custom MyShoppingListBundle
2. MyShoppingListBundle/Migrations/Schema/v1-0/AddSerializedFieldMigration.php was loaded succesfully
3. Created MyBundle/Entity/ShoppingList.php
4. Created MyBundle/Model/ExtendShoppingList.php
5. dev-cache cleared
It happens – nothing!
If I create my custom controller a new ShoppingList-instance it does not inherit the methods from parent OroShoppingListBundle-class.
May be ShoppingList-entity cannot be extended this way, as it is already extended in OroShoppingListBundle?
(EX_OroShoppinglistBundle_ShoppingList – cannot be created twice behind the scene?)
The important part in this migration (which is different from common Doctrine migrations) is the oro_options key. It is passed through the options argument of the addColumn() method:
Suggested ‘migrations’ code:
PHP
1
2
3
4
5
6
7
...
$table->addColumn('buOwner','string',[
'oro_options'=>[
'extend'=>['owner'=>ExtendScope::OWNER_CUSTOM],
],
]);
...
All options nested under this key are handled outside of the usual Doctrine migration workflow.
When the EntityExtendBundle of the OroPlatform finds the extend key, it generates an intermediate class with getters and setters for the defined properties, thus making them accessible from every part of the code. The intermediate class is generated automatically based on the configured data when the application cache is warmed up.
Obiously this is aresult of having already 3 serialized fields without ‘oro_options’ generated, may be, I have to delete them before trying the version with ‘oro_options_-key?
How I can do this?
Sorry for confusing, and thanks a lot for your help.
I have to delete them before trying the version with ‘oro_options_-key?
Yes, there is no way to roll back the migration, this why it is required to back up the database before running any migrations, so you will be able to restore from the dump.
How I can do this?
With the external tool, like built-in MySQL commands do the backup before running the migration, then restore if something goes wrong.
Looking in more detail, I can provide the full error message:…
As I did not know how to delete SerializedFieldExtension-fields, generated without ‘oro_options’-key, I have setup a new, completely fresh oro 319 CE instance.
Again, migration suggested by EntityExtensionBundle-guidline:
fails with the same error:
In ExtendConfigProcessor.php line 386: Call to a member function getConfig() on null.
Seems to be an incompatibility between SerializedFieldsExtensionBundle, and EntityExtendBundle:
The ‘oro_options’-key is necessary for entity-extension, but it does not work for SerializedFieldExtension!
No identifier/primary key specified for Entity “MyShoppingListBundle\Entity\ShoppingList” sub class of “MyShoppingListBundle\Model\ExtendShoppingList”. Every Entity must have an identifier/primary key.
Obviously the OroShoppingListBundle ‘ShoppingList’ is not / cannot be extended. If it would be extended it would have ‘id’, and other properties/methods inherited.
So, I am not smarter then at the beginning. Unfortunately. :-(
Thanks for ideas.
Kind regards
Frank
PS: Of course I could implement additional colums instead of using the serialized fields feature. But why to make it more complicate, if a toll exists for doing this automated way (and not changing database schema!).
Thank you for sharing the code, now I hope I have got the clue.
If you are extending the ShoppingList entity from the core, you must not create a new entity class or the model. Migration is the only thing you should work with, the extended fields you configured at the migrations will be generated automatically.
And sorry for irrelevant answers, I’m trying to do my best.
Your idea … could work, but it does not, due to/for reasons:
1) Temporarily, I have put a ‘dump($shoppingList);’ into core OroShoppingListBundle-Frontend-Controller (viewAction)-code.
The output on frontend shows a ShoppingList-Object with
– empty serializedFields-property, and
– without any buOwner-property.
2) To access the buOwner-property without extending the ShoppingList-Entity the buOwner-property should be available through the core-Entity.
Or I am wrong?
:-)
—
Meanwhile I tried to make experiments with OroOptions like:
To check that it works I added 3 simple lines in the existing controller \Oro\Bundle\ShoppingListBundle\Controller\Frontend\ShoppingListController::viewAction
Works like a clockwork. In principle, I didn’t do anything yesterday other than what you suggested. Today with a fresh installation but it works.
Andrey, thank you very much for your effort. You really helped me a lot. The way of extending the properties of an entity via the serialized fields will save me a lot of time in the future!
GREAT SERVICE!
Kind regrads
Frank
PS:
For people who are using mySQL instead of postgreSQL, the query above would be:
SELECT convert(FROM_BASE64(serialized_data) using ‘UTF8’) FROM oro_shopping_list WHERE id=2
We collect cookie information with a goal to provide you with the best user experience. By using this website, you agree to our use of cookies. Read Oro Inc.’s Cookie policy.
We collect cookie information with a goal to provide you with the best user experience. By using this website, you agree to our use of cookies. Read Oro Inc.’s Cookie policy.