Did anybody tried to overwrite a propel behavior?

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.

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.

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 Thx a lot for this information, I may work around this issue too.

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