Simple question, but I am spending a lot of time without finding a solution:
Oro works with automatically generated entity-extended cache-classes like
EX_OroCustomerBundle_customerVisitor.php.
Using the oro phpStorm plugin, phpStorm detects those classes with its methods, and suggests not only basic OroBundle-entity-class, but although the dev-cache-entity-extended class ‘EX_ …’.
I have one phpStorm project with perfect working plugin. However in another new fresh project of the same phpStorm-instance, and same oro commerce version 3.1.x the oro plugin does not work at all.
Plugin is enabled (one can enable/disable it for all projects of an phpStorm instance only), and I did not find any differences between the 2 projects.
Is there anybody from oro-dev-team, who has got the same experience, and may be found a solution … ?
No, Symfony plugin is on place, and configuration has been checked (at least it is the same as the working version …).
It is strange:
I have extended shoppingList-Entity via Migrations with custom field buOwner (businessOwner) … as an alternative to serializedFieldsExtension.
Ex_OroShoppingList_ShoppingList.php – class has been created in dev-cache, with setBuOwner() and getBuOwner() working like a clockwork (behind the inspection …)..
However if I create a new ShoppingList(), I can set $shoppingList->setBuOwner($str), and it is stored in db, finally. But IDE suggestion is not working. ->setBuOwner is not listed as a suggestion.
If I use mouseover for inspection,
$shoppingList = new ShoppingList(),
phpStorm says, that this is a OroShoppingListBundle/…/ShoppingList-object,
but it should say that it is an EX_OroShoppingList_ShoppingList-object.
It is the same behaviour in OroCoreBundle, or myCustomBundle.
And in another mirrowed project, it works fine.
No idea, what should I do. Inspection shows errors (missing methods … and more), but those errors are not corresponding to reality.
“The error happens because MySQL can index only the first N chars of a BLOB or TEXT column. So The error mainly happens when there is a field/column type of TEXT or BLOB or those belong to TEXT or BLOB types such as TINYBLOB, MEDIUMBLOB, LONGBLOB, TINYTEXT, MEDIUMTEXT, and LONGTEXT that you try to make a primary key or index. With full BLOB or TEXT without the length value, MySQL is unable to guarantee the uniqueness of the column as it’s of variable and dynamic size. So, when using BLOB or TEXT types as an index, the value of N must be supplied so that MySQL can determine the key length. However, MySQL doesn’t support a key length limit on TEXTor BLOB. TEXT(88) simply won’t work.”
STEP 3 (solution)
—
I modified my migration as follows:
After appliing this, phpStorm recognizes all EX_OroBundle_ …-superclasses, and all is fine now!
CONCLUSION:
—
May be, it makes sense for OroDev-Team to adapt OroEntityExtendBundle and Oro-Platform-plugin for phpStorm, both in that way, that USING for custom property A KEY WITH LENGTH less then allowed (by mysql …) for indexing, will RESULT IN A CLEAR ERROR during oro:migration:load –force!
Hope, this was helpful for other who is beginning to work with oro application.
Kind regards from Germany
Frank
Author
Replies
Viewing 4 replies - 1 through 4 (of 4 total)
The forum ‘OroPlatform’ is closed to new topics and replies.
You will be redirected to [title]. Would you like to continue?
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.