LCS - Data Model best practices
- Schema Design
- Relationships
Schema Design
A data schema defines how data is organized within an application; this is inclusive of logical constraints such as model names, properties, data types, and the relationships between these entities. In Betty Blocks, unlike traditional database design, we use the term Model to define what could be considered a table.
LCS - Development Naming Conventions for Betty Blocks
Schema View
Betty Blocks offers a view that allows a developer to visually see all the models and relationships in an application at once. We highly suggest you not use this view as it is buggy and does not always show the correct relationship status. We have a Bug into Betty Blocks on this issue.
Properties
Settings
The settings tab of a model holds several useful options to make using models on the platform faster and more efficient. It is highly recommended to use these options.
Labels
Use the label option to preset which model property should be used in selects, auto-completes and multi-auto-completes as the display text. Setting this will allow you to leave that setting blank unless you need to change it for that specific input.
Sort order
Setting the sort order of a model presets the order in which a selection of model data will appear in Data Lists and Data Grids.
Settings models
If the model you are creating should hold the same data no matter which sandbox (environment) is being used, utilize the settings model option to ensure that data is consistent across the application.
Validations
Model validation is key to ensuring the data in your application is valid and correct. Validation is done on a per property or relationship basis; the validations tab only shows what validations are in place on the model. Here are some use cases for when you should and should not set validation on a property or relationship.
When to enforce validation
- When the property or relationship is expected or needed for display or logic purposes, enable required. Also, remember that if the field needs a value but is not set at creation time this will cause the model record creation to fail. Set a default value, if appropriate, to avoid this issue.
- When a property value must meet certain length criteria, enable the max or min length validation.
- When a property must be unique across all records in the model, enable “Has to be Unique”. An example of this would be requiring an email address to be unique for a user model.
- When a single-line text field is expecting only certain values, use the “must be one of” option to restrict what values are allowable.
When not to enforce validation
- When a field or relationship is optional or may not exist at the creation of the model record, only set ‘required’ when also setting a default value for that property.
Permissions
The permissions tab on a model is a holdover from the Classic UI in Betty Blocks and will be removed at some point. However, understanding how to set the permissions on a model (specifying who can and cannot create or update a model) is important. Two mechanisms are used to set model permissions in Next-Gen Betty Blocks: action permissions and role permissions.
Role Permissions
Under tools -> roles and permissions, each role will have the list of models in the application and a setting for if that role should be able to “read” that model. If that role needs to be able to view any data from that model or interact with data from a relationship of that model, read must be enabled or the fetch of that data will fail and can break the application. Additionally, if a role should only be able to read data from a model that they created or own (or some other use case), then apply the filter option to dictate what records of the model that role can see.
Action permissions
Every action has two modes, public and private. In public mode the action runs with no restrictions and can technically be run by a non-authenticated user. Actions that need to be run on a schedule require this setting as the concept of a scheduled task user does not exist in BB. Any action using this method should be carefully crafted to ensure it’s not potentially exposing data that it should not.
Private actions require an “Auth Profile” to be attached to them and once attached, the roles of the application can be set to whether they can run each action or not. This is how a developer can restrict who can create/update/delete a model by only enabling an action for the user role that should be able to complete that task.
Relationships
One to Many Relationships
A one-to-many relationship is used to define relationships where a single model is the parent to another model. (That ‘other’ model may itself be a parent to yet another model.) For example, a blog post may have an infinite number of comments.
Selecting the right type of relationship.
HasMany or BelongsTo
As the name suggests, a HasMany relationship indicates that a model may have one or more connections to another model. The inverse of that is that a model may belong to another model.
As an example, a blog post can have many comments and a comment can only be for one post. In this scenario, a post may have many comments. The inverse of that would be that a comment belongs to a post. When you create this type of relationship on either model, Betty Blocks automatically creates the inverse relationship, also. We suggest adding the relationship to the parent model (that will use the HasMany relationship) as that is easier to apply correctly.
Many to Many Relationships
Many-to-many relationships are slightly more complicated than HasMany relationships. An example of a many-to-many relationship is a post that has many tags, and those tags are also shared by other posts in the application. For example, a post may be assigned the tag of "Travel" and "Trip"; however, those tags may also be assigned to other posts as well. So, a post has many tags, and a tag has many posts.
Choosing between a HasAndBelongsToMany relationship and a Bridge model
To seasoned developers the concept of Betty Blocks many-to-many relationships structure can be confusing as in traditional database design many-to-many relationships always have a “pivot” or “join” table associated with them. In Betty Blocks this is not the case. The default many-to-many relationship obfuscates the “pivot” table from you so when saving or updating a model with a many-to-many relationship all the developer needs to do is save the relation data and Betty Blocks will handle the translation to the hidden table.
Bridge models are a Betty Blocks term for a “pivot” or “join” table/Model that adds some additional field(s) to the intermediary table, therefore requiring an additional model. If no additional field(s) are required for the intermediary model, then a standard HasAndBelongsToMany relationship should be used. For more information on how to create and use bridge models see (KB link to using a Bridge model).