Why a custom attribute created on parent CMDB table, creates the attribute on all its Child tables?

[Suggy]

When a custom field created on parent CMDB table, it creates the same custom field on all child tables.

Ex: I create a field 'u_test' on cmdb_ci_server, it then created this field explicitly on all its child tables (like on windows, linux, solaris tables etc) . You can see several entries in dictionary.

This is not the case with Task table. ie if I create a field on Task table, its stays there, but I can can reuse that field in its child tables.

Any reason behind this?

[Community Alums]

HI @Suggy ,

Task and cmdb_ci tables are parent tables, these table properties are inherited by child tables when u extends parent table while you creating custom table. Anytime you add new field to parent, that field will automatically be inherited by all child tables. That is, there is nothing more that you need to do to make new custom field of parent to appear in all child tables.

Original table	Related tables extended from original table
Task [task]	Incident [incident] Problem [problem] Change Request [change_request]
Configuration Item [cmdb_ci]	Application [cmdb_ci_appl] Computer [cmdb_ci_computer] Database [cmdb_ci_database]

[Suggy]

Hi @Community Alums My question is totally different 🙂

[Suggy]

Anyone?

[SteveMacWWT]

@Suggy You need to go back and check your statement that task tables do not inherit new fields from their parent. This is incorrect. While @Community Alums‘s response may not have directly answered your question, if you read into it a bit, you’ll see that he is saying the same thing. 

As to why do they do this? That is the idea behind having child tables (either CI classes, or Tasks): so you do not need to redefine new attributes on all children tables. This also leads into the capability of querying across the child tables, using the same field.

For example, if you were able to define a new field on Task for tracking the building it was created in, and then needed to query for all tasks created in Building X, you could filter the task table by searching on u_building_created_in = Building X. 

If on the other hand you did it by creating the field separately in each sub-task table, your filter would need to include something along the lines of:

incident.u_building_created_in = Building X

OR

change.u_building_created_in = Building X

The same type of logic holds true for CI Class tables.