Define data storage schema for webform 8.x. [#2453511]

In #2449383: Select list component display incorrectly orders items; should match component order there is discussion of ways to better allow components to get back their data in the order sent to the database. The 'no' column in string, so that numeric indices sort in alpha (1, 10, 11, 2, 3 ... 9) order rather than numeric (1, 2, ... 9, 10, 11) order.

This lead to a discussion about ways to sort the 'no' column, which is overloaded. For grid components, it holds the "sub-component" key -- e.g. the question's key. If we wanted to make a multi-select grid component, there would be no ready way to store the data.

One solution might be to extend the table to have a 'no' which is like the core delta or weight column -- a numeric increasing index representing values in a particular order, and some other "sub" columns, representing multiple data for one "no" index. This would allow multi-select grids.

This issue is for discussion of the right schema for D8, when the time is right to have such a discussion. Should there ever be a 7.x-5.x version, such decisions could possibly be backported to it.

D8 maintainers -- feel free to adjust the issue status, priority, etc as you see fit. Thanks folks.

Comments

Comment #1

DanChadwick CreditAttribution: DanChadwick commented 28 March 2015 at 13:13

Here's a proposal as a talking point for webform_submission_data:

nid
node_machine_key -- like a bundle, but for submissions. Allows groups of similar webforms to be grouped together for aggregation, views, analysis, and reporting. Denormalized.
sid
cid
cid_machine_key -- allows views reporting without having to know node-specific cid. Denormalized.
delta -- a numeric field used to store multiple un-keyed values, such as a multiple-valued select.
sub_machine_key -- allows storage of sub-component data, such as question key of a grid or (proposed) checkbox grid
data -- the string value of the data
number -- the numeric (float) value of the data, if any. Denormalized.
date -- the date/time value of the data, if any. Denormalized.
hash -- the hashed value of the delta, used for unique value indexing and providing compatibility with MS Server which can't index text components. Denormalized.

Comment #2

DanChadwick CreditAttribution: DanChadwick commented 28 March 2015 at 13:18

Title:	webform_submissions_data table schema not very flexible	» Define data storage schema for webform 8.x.
Priority:	Normal	» Major
Status:	Postponed	» Active

Comment #3

DanChadwick CreditAttribution: DanChadwick commented 1 April 2015 at 20:37

In order to support more-than-one of any webform component, we'd need another super-delta column. So that means:

delta -- monotonically increasing array of integers, representing which of many possible values. Use case: multiple values in a select component.
sub_machine_key -- an alphabetic (meaningful, feature-able) index of which sub-component contains the value. Use case: question keys in a grid component.
super_delta (or whatever the name) -- a monotonically increasing array of integers representing which in a series of field groups this appear. Field groups would not be nestable.

This would allow grids components to both have multiple-select questions and appear in field groups.

Also, unrelated to the above, is the question of not storing empty values, as is done today in D7. #2463149: Storage of empty component values wasteful

Comment #4

heddn

English

Nicaragua

CreditAttribution: heddn at MTech, LLC commented 29 February 2016 at 17:41

Cross-posting from #2075941: Port Webform to Drupal 8.

Take a design page from multifield in D7 (and CCK in D6). For all fields with cardinality of 1, store those values with a special storage handler that puts them as properties on the base db table. For all fields with a cardinality of greater than 1, store them using the normal D8 storage handler.

The idea here is that the primary use case in D8 for Webform is for really *long* forms. Most simple use cases could use something like https://www.drupal.org/project/contact_storage & core contact, which solves +/- 80% of form needs. But there are going to be massive forms that having lots of fields just isn't going to scale. But even in the case of those *long* forms, most of the fields are cardinality of 1. So, storing them as properties get's around most of that problem. In the more rare case that a form field needs to have a cardinality greater than 1, then the author of the form can just change the cardinality and the field will get storage as per normal D8 methods.