You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Repeatable groups were deliberately exempted from support for storing data in individual meta keys in #255:
The only way to support such a structure would be to save to meta keys like group_0_field, group_1_field, etc., which would not be sustainable and it would be difficult and inefficient to work with in code. In every situation where an ancestor's limit != 1, it's much better to use serialized data.
This makes sense for groups that have an ancestor, but it's not clear why the group at the top level of the field hierarchy would need to use the meta key structure outlined above. Instead, individual meta keys could store individual associative arrays.
My own use case for this enhancement is an "RSVP" group where each group represents a user-submitted RSVP. While storing all of the RSVPs in a single array works well enough, conceptually it would make a little more sense to me for each response to be stored in its own row.
The text was updated successfully, but these errors were encountered:
Repeatable groups were deliberately exempted from support for storing data in individual meta keys in #255:
This makes sense for groups that have an ancestor, but it's not clear why the group at the top level of the field hierarchy would need to use the meta key structure outlined above. Instead, individual meta keys could store individual associative arrays.
My own use case for this enhancement is an "RSVP" group where each group represents a user-submitted RSVP. While storing all of the RSVPs in a single array works well enough, conceptually it would make a little more sense to me for each response to be stored in its own row.
The text was updated successfully, but these errors were encountered: