What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hello guys. small question about your architecture approach. You declared that we need to use query

U0145CP9Q6Q
U0145CP9Q6Q Posts: 123 🧑🏻‍🚀 - Cadet
edited July 2020 in Help

Hello guys. small question about your architecture approach. You declared that we need to use query objects on query containers. But what I see in your data import module that you are using query objects directly in writer steps. For example here \Pyz\Zed\DataImport\Business\Model\ProductAbstract\ProductAbstractWriterStep or here \Pyz\Zed\DataImport\Business\Model\Customer\CustomerWriterStep . Actually everywhere. Was it any specific reason to do so? Why didn't you inject the appropriate query containers in constructor of writer steps classes? Because I'm implementing import steps for my custom entity and I'm confused with your approach. thanks

Comments

  • UQ958DA4U
    UQ958DA4U Posts: 232 🧑🏻‍🚀 - Cadet

    I'm not a Spryker representative but I can tell you that any bit of indirection causes a major performance slow down. The less indirection the better it is. Especially for a lot of data sets.

    Another idea that's important here is that Writers using Propel can only be considered a "quick and dirty" solution. They are not fast at all and performance can always be improved by at least going to their BulkPdo counterparts, which I would recommend.

    Hope this helps.

  • U0145CP9Q6Q
    U0145CP9Q6Q Posts: 123 🧑🏻‍🚀 - Cadet

    hm. i don't think that such inderections will cause any performance issues.. 🤔

  • Andriy Netseplyayev
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 519 🧑🏻‍🚀 - Cadet

    In addition to what Thomas says:
    • It would be much harder to build complex import cases which often involves more than just one entity that intersect with each other, using query containers. You would either have a huge DataImportQueryContainer or multiple module-specific one-s.
    • Important is also, that you would better not re-use those queries (as one of the goals of QC) and not tempt to change them. The whole Writer should better stay isolated
    • Performance - is a very important topic too. In this case, isolated writers with their propel queries is much easier to replace with direct PDO queries as a first step and then bulk-PDO queries as a second step.

  • Andriy Netseplyayev
    Andriy Netseplyayev Domain Lead Solution Architecture Sprykee Posts: 519 🧑🏻‍🚀 - Cadet

    “quick and dirty” - yes, this is a good term for writers

  • U0145CP9Q6Q
    U0145CP9Q6Q Posts: 123 🧑🏻‍🚀 - Cadet

    ok. thanks for clarification

  • UKGT7RC7P
    UKGT7RC7P Posts: 538 🧑🏻‍🚀 - Cadet
    edited July 2020

    random, unsolicited, tip: don't put them in the DataImport module like all the Spryker importers, write plugins (?) in the modules to which your importer belongs

  • UKGT7RC7P
    UKGT7RC7P Posts: 538 🧑🏻‍🚀 - Cadet

    DataImport module can become hugely bloated

  • UKGT7RC7P
    UKGT7RC7P Posts: 538 🧑🏻‍🚀 - Cadet

    (in our experience at least)

  • Unknown
    Unknown

    Usual recommendation is create a separate module which belongs to your entity with DataImport postfix. eg CustomEntityDataImport

Categories