Import relationships

I found some instructions on the web for the combination of WP All import & CIO Custom Fields Importer plugin, but i still can’t make it work:
https://vipp.com.au/cio-custom-fields-importer/how-to-match-and-import-relationship-fields-into-pods/

It gives this example of importing relationships into pods:

—————————————

Example 3, custom field related to a custom field using pods table storage

MATCH for item id in PODS TABLE, from column translations ( translations : {translations_available[1]} )

—————————————

Is this “import template” supposed to be the field in the WP All import plugin? I’ve tried it, but doesn’t seem to work…

Any help?

• This reply was modified 6 years, 2 months ago by mark500.
• This reply was modified 6 years, 2 months ago by mark500.

If you’re not using the premium version of CIO Custom Fields, you can only do the following with the free version:

The free version supports single select relationship fields with known item ids. The pro version handles multiple select fields, and auto matching items on a live site.

If you’re setting that configuration up for import, that means your import file needs to only have the post id of the ‘matched’ record in the column for the relationship field. When I’ve done this methodology, I’ve exported that one post-type after importing so I have the post ID’s and then used Excel to do a VLookup on that table with post-id’s to match the post ID’s into the other table for the relationship. If you didn’t have too many relationships, you could do this manually I suppose, but this is the method you’d have to do when using the free version. You have to use actual post id’s from the related custom post type in the column for your relationships for import and as indicated above, this will only work for single select relationships.

The only way the ‘match’ method works is if you have purchased and are using the pro version. We don’t provide tutorials for this version, because we don’t support this version. They do provide instructions on their website (which you have referenced)

We do not provide support for the premium version as that is handled through CIO’s website when you purchase the premium version (https://vipp.com.au/cio-custom-fields-importer/contact-us/)

I hope that helps.

Yes, it does help! Thank you for explaining this to me.

I’ve contacted CIO’s support and they are helping me figure it out how to achieve this.

P.S.: On the side note, they wrote:

By the way, due to a bug in pods two way relationships, some customers experience issues when importing two-way relationship fields. The issues were gone when changing the fields to one way relationship. You may consider using one-way relationship (one to one, or one to many), and use custom template/custom query to list the related items. PODS two-way relationship fields write index twice, not efficient, and are difficult to scale when the data accumulates.

Do you know what they are talking about, maybe this is a new bug or already fixed?

We’d actually disagree that the bidirectional relationships aren’t ‘efficient or difficult to scale when the data accumulates’.

What this means is that when you configure your relationship, let’s say from Books to Authors, you have a relationship field into ‘Authors’ from Books called ‘Related_Author’. That’s a one way relationship and it writes the connection ‘once’. We also support Bidirectional relationships, meaning you can also have a relationship field in ‘Authors’ to ‘Books’ called ‘Related_books’ and it uses the other relationship to automatically make the other link valid.

Yes, if you had one that was hundreds of connections, I could see where that might be inefficient, but typically in that kind of situation, you’d probably use our Table Storage anyway and it would be a non-issue.

They’d need to provide more details as to why they consider this a ‘bug’. You’re welcome to forward the email to us at [email protected] and I’ll make sure it gets looked into.

Thanks!

Just wanted to jump in here and note that on a technical level, Pods stores bidirectional relationships as two rows in our relationship table. That’s probably what they’re referring to. We do this because it makes querying with indexed data in the table more efficient, versus writing logic that checks multiple columns in an SQL JOIN of the relationship table. We don’t just relate, we let people query the relationships and traverse them. There’s not a way to store them in a single row without creating inefficient JOIN queries, so we opted for more efficient day-to-day querying.

Hello, I am the developer of CIO custom fields importer plugin. I have just noted the email has been quoted above in this public forum, which was my opinion intended as a private conversation to address a particular use case. Just in case someone reading this thread in the future might misunderstand the quoted email out of context, here is the revised sentence regarding two-way relationship

PODS two-way relationship fields write index twice, not suitable for batch import, and are difficult to scale when data accumulates.

Scott’s comment above has provided insight on a technical level. The current implementation of two-way relationship fields uses two records to represent one relationship, instead of looking up the same record in two different ways. This doubles up the work when writing to a database. If one author has 10 books, you will end up with 20 records for one bidirectional relationship field (instead of 10 records when using one way relationship). Now suppose a productive author has 50 books, or you have 5 similar relationship fields(each relating to 10 items), when a post is created/updated, the database server needs to take care of 100 records (instead of 50 records). It will reach a point beyond what a database server can handle within a short period of time, especially on a shared hosting environment. This will cause the import to fail when writing data at high speed, repeatedly. The problem will get worse when your data grows.

In my email, I was trying to say you need a data structure to suit your current and future needs.

With that said, in my opinion, PODS is still the best plugin to handle custom fields with great support, and a good potential to scale up. It has provided an alternative way to store custom data in a separate table (aka table storage), in addition to postmeta table. Some customers have imported over 20,000 records with the trio (WP All Import, CIO Pro, PODS) in one go.