Skip to content

Field value constraints

Problem Statement

An area that baserow currently lacks in is validating the values stored in fields beyond the restrictions imposed by the field's type.

Example constraints include (in rough order of "likely widely useful" to "less widely useful but still useful"):

  • The field must not be empty (non-null)
  • The number of rows on the opposite end of a 'link to table' field must be within an upper and/or lower bound (allowing strictly one-to-one and one-to-many associations)
  • The field's value must be unique within a table if not empty (uniqueness)
  • A numeric field's value must be within an upper and/or lower bound
  • Common string validations (minimum/maximum length, not included in a denylist, possibly arbitrary regex matching)

Who will benefit?

I would foresee that almost every user of baserow would find some form of constraint listed above useful.

Benefits and risks

Baserow is already positioned in a useful spot somewhere between a spreadsheet and a relational database, making it useful for many forms of data collection that would otherwise be more difficult or error-prone with a traditional spreadsheet whilst still not justifying a full relational database with a custom frontend.

Adding a simple set of optional constraints similar to those described above or otherwise would expand baserow's field of applicable use cases to those where a traditional application such as Microsoft Access might be used.

Potential risks/downsides:

  • Increased user complexity (low) - Some of the targeted users of baserow may not possess the skills necessary to configure more complicated constraints, such as those using regular expressions. This can be made a non-issue by hiding such functionality in such a way that it doesn't overwhelm the user before opting into it - such as behind a "Use advanced field constraints" or similarly named checkbox at the bottom of the edit field popup.
  • Performance impact (low to medium) - All of the constraints for a row would need to be checked on create/update. Some of the above-mentioned constraints could be offloaded to Postgres. Additionally, constraints would need to be checked for all rows when set on a field, in order to ensure that existing data satisfies the constraint. If some rows do not satisfy the new constraint, an error would need to be presented to the user (potentially offering an option to set the constraint anyway - with the idea that any rows violating it would need to be fixed when next updated).

Proposed solution

This proposal could easily be split into multiple stages - for example¸ required fields could likely be added very easily by themselves.

In general, my idea is all constraint configuration would be within the edit field popup, potentially under an expandable section. Only constraints relevant to the chosen field type would be displayed (keeping in mind that some constraint types such as non-null would be relevant to all field types).

The easiest way to implement it on the backend (from a quick browse of the codebase) would likely be to have RowHandler check constraints on fields when a row is created/updated.

Examples

Most of the inspiration for this has been taken from relational databases eg. Postgresql. Similar applications to baserow such as NocoDB include some degree of constraints.

UI/UX Design Required

  • Substantial (This involves the creation of entirely new pages, layouts, many new components which don't exist in the style guide)
  • Some (Mainly involves re-use or duplication of existing UI components with minimal customization)
  • None (No UI/UX work required for this feature)

Priority/Severity

  • High (This will bring a huge increase in performance/productivity/usability/legislative cover)
  • Medium (This will bring a good increase in performance/productivity/usability)
  • Low (anything else e.g., trivial, minor improvements)