Did anybody tried to overwrite a propel behavior?
Did anybody tried to overwrite a propel behavior?
As propel loads them from composer.lock file I didn’t found any point to extend an existing behavior.
Comments
-
To be more specific I need to overwrite the sync behavior from the Spryker core and neither does it follow any Spryker principle for overwriting nor is it overwritable by composer as it’s not loaded by a namspace but by directly parsing all composer.json files of all vendor packages and looking for an “extra” field.
0 -
I am not sure that I understand. Are you trying to replace propel dependency with own fork/version?
0 -
to do that you need to add repo of the fork to composer.json
{ "type": "vcs", "url": "<https://github.com/my_fork/Propel2>" }
0 -
and then
"propel/propel": "your_branch_name as 2.0.0-alpha8",
0 -
No, that would be easy.
As there is no way to see how complete the search/storage is we’ve added our own module to find any diffs.
To make it a lot more efficient it can trigger resync’s without rabbitmq involved as rabbitmq drops events when you try to write to much into it.
For normal storage tables it’s pretty easy to write a direct sync, but some (e.g.: product_concrete_storage) do not only export a storage entry but also a mapping.
When you want to clean orphan keys from the storage you need to make sure that you do not clean a mapping where the main entry (product concrete in the example) still exists.
Therefore I need to know which mappings are exported per entity, but this is an information not available outside of the entity. So I thought extending the sync behavior to make this information available would be the easiest way.
If propel would fully use the autoloader it would be straight forward, but sadly for behaviors they implemented their own mechanism, based on parsing composer files.0 -
In the end it comes down that there is no documented possibility to overwrite: https://github.com/spryker/synchronization-behavior/blob/master/composer.json#L34
0 -
Maybe the following give a better idea what we have build:
It show what storage entries are complete, which are incomplete and if we have to many (orphan) entries (the yellow state)
0 -
Hi, I asked the support some month ago how I can do it and got this as the answer "Propel is working with behaviors in a "fun" way. Namely, it loads them automatically from the list of installed packages. So it is not so simple.
If there is no extension support in the module itself, they can make their own by expanding ours on the project level." So for my problem I found another way to solve my problem without overwriting the behavior0 -
@UK7KBE2JW Thx a lot for this information, I may work around this issue too.
0 -
you are welcome
0 -
A hacky solution I found is to set the whole project type to “type”: “propel-behavior” in composer.json and add the appropriate extra section:
“extra”: {
“name”: “synchronization”,
“class”: “\Pyz\Zed\SynchronizationBehavior\Persistence\Propel\Behavior\SynchronizationBehavior”
}0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 69 Spryker News
- 896 Developer Corner
- 758 Spryker Development
- 83 Spryker Dev Environment
- 361 Spryker Releases
- 3 Oryx frontend framework
- 34 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 23 Job Opportunities
- 3.2K 📜 Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 32 Product & Business Questions
- 68 Spryker Safari Questions
- 50 Random