Different storage type

• aegon

• April 19, 2020 at 4:07 am

Hi there,

I have a question regarding the field data storage type in the database.

I’m slightly confused here because when I was doing the transition over to ACF, I did some research and noticed that in general, ACF does not care about the number of records it does in the database.

1. First off, each field comes with it’s “key” related duplicate so we’re getting 2 x meta fields at the very start. I’m not sure why the plugin cannot use some sort of a Register that would store the field types to save the database space? Is there a good reason for adding so much data to the database?

2. So, taking the above on side, I don’t understand why a field like Gallery or Checkbox stores data in a serialized way? The entire concept of storing the data in separate fields (which is the case for the Repeater field for example) is ruined and I have a complex value stored in the database instead of adding those values as separate records with the same meta_key value which is the native WordPress way to do so.

Since the data is stored as serialized value, we have to use the “LIKE” operator in our meta queries that is over THREE HUNDRED TIMES slower than a simple EQUAL “=” that would be available to use if the data was not serialized.

– –

Is there any way to get the developer’s attention to this? I’d really love to hear some comments on that and the reasoning behind going for such different approaches in various parts of the plugin.

We’d really love to move over to ACF for ALL of my projects in the upcoming future but the above concerns our company as heck.

Kind Regards,
F.

• John Huebner

• April 20, 2020 at 4:25 am

I am not the developer, just a long time user that has gotten to know the workings of ACF. If you really want to get the developer to weight in then you’ll need to submit a request here https://www.advancedcustomfields.com/contact/

1) The reason that there is a field key for each field is so that ACF knows how to treat that field value. The issue is that any field name can be repeated. Let’s say that you have a field named “some_field”, this is a simple text field and the data of this field is save for a “Post”. Now let’s say that you create another field with an identical name and you save this field value to “Pages” but is field is a relationship field. The only way that ACF knows how to treat these two fields differently and return the correct value is that each of the fields has a different field key reference.

Many people are under the mistaken impression that ACF “knows” or “remembers” what fields are used for what post type, taxonomy, user, options page, etc. It does not. When ACF gets or saves a value two pieces of information are required, the post ID (or some other object ID) and the field key. When you are saving a value ACF has this information when the form is submitted. When retrieving a value when you use the field name ACF must look up the correct field key.

This is the reason that a field key reference is needed. The only way that this would not be the case would be if ACF required a unique field name for every field created.

2) Fields are stored separately, values in those fields are not always stored as separate values. A selection in a gallery field is not a sub field of the gallery.

So it might be possible to store the values of a gallery field in multiple entries. This would require deleting all values before updating. Then ACF would need to loop over the values and insert each. This action of deleting and then adding multiple entries could cause a performance issue in the admin. Imagine that you have 20 fields like this and each of these fields has 20 entries. This would do a total of more than 400 queries to insert the values. This is because of the way that WP meta values work.

Another issue with doing this at this point would be backwards compatibility. Changing the way ACF stores the values now would be difficult.

There are ways to overcome the issues with doing “LIKE” queries on meta values. You can see how I overcome this by reading the post I created here…. well, it seems that site is now gone….

Anyway, the idea behind what I wrote is to convert fields that you want to query by to standard ACF field. For example, lets say that I have a checkbox field and the checkbox field has values that I want to query by.

add_filter('acf/update_value/name=my_checkbox_field", "convert_my_ck_to_wp", 20, 3);
function convert_my_ck_to_wp($values, $post_id, $field) {
  $search_field_name = 'my_checkbox_field_wp';
  delete_post_meta($post_id, $search_field_name);
  if (is_array($values)) {
    foreach ($values as $value) {
      add_post_meta($post_id, $search_field_name, $value, false);
    }
  }
  return $values;
}

Now a query can be done using the alternate field name. This does create extra data in the database, but this is not nearly as detrimental to queries as doing a “LIKE” query on the ACF value. And since we only do this on fields where we need the values stored this way there is less likelihood of the performance issues we might have if every ACF field was stored in this manner.

• aegon

• April 20, 2020 at 6:32 am

Hi John,

Thank you for your response. I appreciate it. I’ve seen you being very active on the forums. Actually much more active than the developer himself.

1. I understand the reason for the second meta field. I know ACF stores that specific extra little information there. I’m just curious why this approach was taken instead of some sort of a pure PHP registry that would store this information and would not require this database bloat. I’d love to get some insight from the developer here. I’m not saying this is bad, I’m just trying to learn and understand the reasoning behind it. There is no information about it in the docs.

2. Yeah, I’m aware of that but if we go this way, we can say the same about the Repeater field: why not store the entire “Repeater” field as a serialized meta? It would just be a single meta field update operation. Instead of that, if you have a Repeater field consisting of 10 fields and you create 20 entries with it, you end up with 200 meta fields to update. And that’s only one repeater field. Imagine you have 5 of those. Yeah, you end up with 1000 meta fields per single post.

I’m trying to understand why such a “separate fields” approach was taken for the repeater but not for the other fields? I wouldn’t be asking if either one or the other was used for every case, consistently – but it’s not the case. I’m really curious about it as I want to learn the concept so I can use the plugin with full confidence for my clients.

And thank you for posting the snippet: I’m perfectly fine writing my own code but I truly want to use the plugin for meta box management as it is, without a need to do any sort of hacking for such core functionality as the data storage type.

If there is good reasoning for all of the above, I’d LOVE to learn and get to know it. Whether it’s about the backward compatibility or something else, it would be good to know.

Thank you so much.

PS. I’m a little worried about the recent activity of the plugin developer. Based on Elliot’s profile, I can see the forum replies count varies between 1-2 per month. I understand the support is being taken care by the support ticket system but I have posted there regarding a different issue and haven’t got any response for 4 days now. I’m a bit worried about the state of this matter?

• John Huebner

• April 20, 2020 at 10:21 pm

As for the developer not being here, he does not visit the forums much if at all. That’s why I’m here so that he can devote more time to working on ACF. I do my best to answer what I can and hope that other users can answer the questions I can’t. The support tickets submitted go to other people, and unfortunately I think that E is not having much luck at keeping skilled people to help him there, so he’s dealing with those himself the way he used to deal with this forum himself until I came along. This is likely why it takes so much time to get responses to tickets. I imagine that he get many of them every day and can’t keep up.

To answer, why not go that way with the repeater field. This would mean treating a text field in a repeater differently than a text field that isn’t in a repeater. The repeater is just a wrapper that creates recursion. The only difference in ACF between these two things is that the one in the repeater has a parent field and the field name is prefixed when saving to the DB. This is what gives ACF the ability to nest fields infinitely. Without recursion it would be much more complicated to accomplish this.