Entity Concern Framework
In order to keep the system flexible enough without adding a heavy amount of work for it, a custom fields framework was created. Its core functionality is to be able to create multiple fields in the database without the need to physically create those fields in the DB, but still save them with their corresponding values as a JSON in a no-sql fashion. There are two main files for using the framework. Entity.rb: it takes care of saving the value of a given new attribute in the core_fields column in the database. Fields.yml: lists the fields of given a model that uses the entity concern. It also manages different options for those fields like pii, searchable, field types, etc.
-
Include the entity concern to the model you want to create. Chances are that if you want to modify an existing model, the concern was already included.
-
Add the new attribute to the model you want to modify with the “attribute_field” accessor.
-
Add the same fields used in step two in Fields.yml
Treat those attributes as any other active record field. You can add validations, override field names, etc. Note, as shown in the screenshots, that if the added field is not a string you will have to specify its type. For enum types, you should describe the possible options in fields.yml. For access those options to make validations:
When using the option “copy: true”, as it is used for “isolate_name” in Batch.rb. The attribute must have its own column in the corresponding (in this case, batches) table. Meaning that the field should be created in the migration.sa
This option copies the value for that attribute in the table column and also in the JSON saved in core_fields
This is useful when you have to perform actions over that column’s values, such as filtering in an index view, for example.