Did anybody tried to overwrite a propel behavior?

Alberto Reyer
Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
edited June 2023 in Propel ORM

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.

Tagged:

Comments

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer

    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
    UKHD8KTMF Posts: 393 🧑🏻‍🚀 - Cadet

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

  • UKHD8KTMF
    UKHD8KTMF Posts: 393 🧑🏻‍🚀 - Cadet

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

  • UKHD8KTMF
    UKHD8KTMF Posts: 393 🧑🏻‍🚀 - Cadet

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

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer
    edited July 2019

    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
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer

    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
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer

    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
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet

    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
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer

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

  • UK7KBE2JW
    UK7KBE2JW Posts: 463 🧑🏻‍🚀 - Cadet

    you are welcome

  • Alberto Reyer
    Alberto Reyer Lead Spryker Solution Architect / Technical Director Posts: 690 🪐 - Explorer

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