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
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
-
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.
0 -
hm. i don't think that such inderections will cause any performance issues.. 🤔
0 -
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.0 -
“quick and dirty” - yes, this is a good term for writers
0 -
ok. thanks for clarification
0 -
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 belongs0 -
DataImport module can become hugely bloated
0 -
(in our experience at least)
0 -
Usual recommendation is create a separate module which belongs to your entity with
DataImport
postfix. eg CustomEntityDataImport0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 75 Spryker News
- 924 Developer Corner
- 783 Spryker Development
- 88 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 35 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 25 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
- 70 Spryker Safari Questions
- 50 Random