OK to save object with superfluous properties to database?

In our app in UI Builder, we often create and manipulate objects that contain some properties that are temporary or which should not be saved to the database.

I understand that if dynamic schema definition is turned off, any properties that are not defined in the table schema are simply ignored in save or update operations. That’s nice, it means we can simply connect an object to a data API block and run it… without having to worry about “cleaning up” the object to have only those properties that are defined in the database.

This makes for really simple code! For example, we can treat a data model of a block that contains all sorts of components as just a single object. Some of the properties in the data model have names that correspond to columns in one particular table, and we can just save the whole object like so:

We can even save the same object to a different table, the operations will then pick out only those properties that are defined for that table’s particular schema.

Not coming from a technical background, my question is: is this good practice? As long as we never turn on “dynamic schema definition”, is there any harm in doing this kind of thing? Or is it advised to always only include specific properties/values that a table in the database can handle, being careful to never take these kinds of shortcuts? Would love to hear any opinions :grinning:

Generally, the structure of Entity objects, which represent your data from the database, should closely match the database schema. For internal logic, another type of object, such as a DTO, is used to pass data between methods. DTOs may contain additional fields.

The use case you described is really interesting, but we did not anticipate using the “dynamic schema” function in this way. The only danger in your case is the lack of flexibility. If you ever need to use the “dynamic schema” feature, you may not be able to enable it because of the application logic you have implemented.