Can linked objects be created during the import?

[Timonwatteny]

See title, I didn't find it in the documentation.

[BlackbitDevs]

Hi @Timonwatteny.

what do you mean with linked objects? As far as I know Pimcore does not support links currently, see pimcore/pimcore#4419

Or do you mean object hierachy? So for example that you can import objects with the following tree strcuture:

• object 1
  • object 2 (inherits from object 1)
  • object 3 (inherits from object 1)
• object 4
  This is possible with this bundle, please see https://www.youtube.com/watch?v=nyhKJTzTq-4&list=PL4-QRNfdsdKIfzQIP-c9hRruXf0r48fjt&index=1&t=2962s

Or do you mean importing relations? This is of course also possible with this bundle, see https://www.youtube.com/watch?v=nyhKJTzTq-4&list=PL4-QRNfdsdKIfzQIP-c9hRruXf0r48fjt&index=1&t=2352s

[Timonwatteny]

Thanks for the quick reply and excuse me for not being clear enough.

What I mean are indeed relations like the manufacturer in the demo, but with the option that the manufacturer you are importing does not yet exists.

So everytime I create an object and it has a relation, I want to check if the object exists and if it does, just create the relation but if it doesn't exist, create the related object and the relation at once.

Is this clearer for you?

Thanks in advance.

[BlackbitDevs]

Yes, this is possible. You have to create 2 dataports to achieve this

• one imports the manufacturers
• the other one imports products and assigns the created manufacturers to the products
• both dataports can use either the same import file or different ones
• you can even connect those dataports so that after successfully running the manufacturers import the products import gets executed - this way you do not get a timing problem when for example the products import would be executed before the manufacturer has been created

I thought about adding a feature to create non-existing relational objects on the fly. As you specify relations by a so called data query selector in the attribute mapping of the relation field we know everything about the relational object which we want to assign:

When you want to fetch data of the same or another object you can use the following syntax: 
return 'Class:filterField:filterValue:dataField';
This would query a data object of class `Class` which has `filterField` = `filterValue`.

This way when you return for example Manufacturer:name:Adidas for the manufacturer relational field in the products import and there is not such an object, then we could create a Manufacturer object and set its field name to Adidas. But this is currently not the case. The reason for this is that I do not know in which path this manufacturer object shall be created. If I created this directly below / then this would clutter the object tree pretty fast. For this reason I decided against on-the-fly creation of relational objects in favor of using a second dataport where you can define all those settings.

[Timonwatteny]

Oké thank you for clarifying this out for me.

What you say about the tree is true but there could be an option in the mapping: create object if new + the possibility to add the parent ID so we can specify in which folder our new objects will be created.

Another question, do you know how fast the bundle is if we let's say import 10000 products?

[BlackbitDevs]

What you say about the tree is true but there could be an option in the mapping: create object if new + the possibility to add the parent ID so we can specify in which folder our new objects will be created.

Yes but with all the configuration, what would be the advantage of this in contrast of two separate dataports?

Another question, do you know how fast the bundle is if we let's say import 10000 products?

We do a lot to optimize the performance - in speed as well as in memory consumption.
We also have logic which tries to avoid saving objects if nothing changed.
We have logic which checks if since the last import the data in the import file actually has changed - if not, we can skip importing items completely. This makes especially periodic imports quite fast.
We have logic which caches relational objects - so for example when multiple objects have the data query selector Manufacturer:name:Adidas we do not look this up in the database every time but cache the result.
If the same object gets edited multiple times in one import run, then it only gets saved once - for example when multiple import files are used at the same time or when multiple items in the import files refer to the same Pimcore data object.
The absolute times are nevertheless dependent on the number of fields in your object class (including object bricks, field collections etc.). This really defines the time because Pimcore writes the data for such complex fields (also for relations, localozed fields etc.) to separate database tables - field by field. So you cannot say that for a class with 20 fields it needs xx seconds. And of course it also depends on the server where the pimcore is running. But to give you a hint: 10.000 objects will need about 30 - 60 minutes (if none of the objects existed before - if some already existed it will get faster due to above optimizations for periodic imports). In current version 10.000 objects will need about 4 minutes.

[BlackbitDevs]

@Timonwatteny Hope I answered all your questions. If you want to know something else, feel free to open another issue or send us an email.