Did anybody tried to overwrite a propel behavior?

Alberto Reyer

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.

Alberto Reyer

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.

UKHD8KTMF

I am not sure that I understand. Are you trying to replace propel dependency with own fork/version?

UKHD8KTMF

to do that you need to add repo of the fork to composer.json { "type": "vcs", "url": "<https://github.com/my_fork/Propel2>" }

UKHD8KTMF

and then "propel/propel": "your_branch_name as 2.0.0-alpha8",

Alberto Reyer

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.

Alberto Reyer

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

Alberto Reyer

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)

UK7KBE2JW

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 behavior

Alberto Reyer

@UK7KBE2JW Thx a lot for this information, I may work around this issue too.

UK7KBE2JW

you are welcome

Alberto Reyer

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”
}