In my previous post, I showed you how to import programmatically defined ACF data. However, I also mentioned that there are some issues you may encounter when dealing with large datasets, such as those that use the Repeater field.
The Repeater field provides a neat solution for repeating content – think slides, team members, CTA tiles and alike.
This field type acts as a parent to a set of sub fields which can be repeated again and again. What makes this field type so special is its versatility. Any kind of field can be used within a Repeater, and there are no limits to the number of repeats either (👨💻 unless defined in the field settings).
Repeat, ACF Manual
The Repeater field allows you to create a set of fields that can be repeated an unlimited number of times. While this is great for flexibility, it also means that there is no limit to the number of rows or fields that can occur. As a result, you may run into the upper limit of what the database can store.
For those who are familiar with the implementation of the Repeater field, you know that each time a new entry is added to the post that the Repeater is attached to, a new set of records is added to the postmeta
table. Over time, this can become a scalability issue.
That is, the post
table will hold the post to which the repeater is attached. Then every time a new entry is added to said post, a set of new records will be added to the postmeta
table.
Overtime, this won’t scale. More specifically, you’re going to hit a point as to where adding a new row in the repeater won’t work. And this is where the alternative solutions for custom data tables tables for ACF comes into play.
Continue reading