Custom fields

A force of Microbizz and its Record2 objects are custom fields which allows users to extend the objects with data fields according to their own choices.

The custom fields are handled through the class CustomField and have a supplemental class CustomFieldUI which is responsible for handling the interface around creating and editing custom fields.

Custom fields actually rewrites database structures and alters Record2 objects, so they can be accessed naturally through these objects, in the same way as the objects native fields.

Storing custom fields - generation 1

When a custom field is created, it is stored in the customfields table and a proper field is created in the appropriate database table corresponding to the Record2 object. Changing the field type will also alter the table field and can result in dropping data, if the new field isn't compatible with the existing data. Deleting a custom field will remove the field from the table.

Storing custom fields - generation 2

A problem was encountered as a Mysql row could only contain so many fields and some customers had a huge number of custom fields.

To fix this, we have introduced the generation 2 (G2) way of storing custom fields. A Record2 object needs to be compatible with the G2 way of storing custom fields in order to use it, otherwise they are considered using G1 storing.

In order to be G2-compatible a Record2 object must introduce an invisible field named metadata of type Record2::REC_ARRAY and DB type MEDIUMTEXT.

In the G2-model a custom field can be considered bulk. If it is bulk, then no database field is created for it. Instead it is stored in the metadata-field as a part of the array, under the appropriate customX key. If it isn't bulk, it is saved just as in the G1-model.

This means that when changing a field from non-bulk to bulk, the field data needs to be moved between the table field and the metadata structure and vice-versa.

A custom field which is bulk cannot be searchable.

Notice that the metadata field may be used to store other things than just custom fields.

Interface

In order not to confuse the user, the bulk terminology isn't introduced in the interface. Instead it is mutual exclusive to the searchable checkbox, meaning that if a field is marked as searchable, it is hidden marked as non-bulk and if it isn't marked as searchable it is hidden marked as bulk.

A solution moving from G1 to G2 will have non-searchable fields which aren't bulk, but as these fields are edited they will change.

When the maximum number of non-bulk fields have been reached a warning is displayed in the create custom field interface that no more searchable fields can be created for this object.

There is no limit on the number of bulk fields which can be created.

The “please wait” indicator should be shown when saving a custom field as the change of a field from bulk to non-bulk and the other way around, can take significant time.