The FiberMultiContainer Class Model Name

Consider a patch panel card, which has two immediate children: frontports and backports. Since there is only one field for the child class model name, we can ask, “Which child gets to be included in the table, the frontport or backport?” Luckily, this parent does not need to choose a favorite, because the answer is neither. For parents with multiple types of children, you do not populate a default for the FIBERCHILDCLASSMODELNAME; simply leave it null. Instead, assign the parent the class model name FiberMultiContainer, which informs the application that this parent has more than one kind of child, so it should not expect to find a model name in the child class field. Knowing this, if we look at the F_PATCHPANELCARD object class, sure enough we find the FiberMultiContainer model name, as seen in this image:

This model name assists in the delete process because, while the parent does not have the child model name populated, all kinds of children have the parent model name and GUID. Those data, in conjunction with the FiberMultiContainer model name, give the application the path it needs to successfully delete the child records and their connections when you delete the parent.

With all of this in mind, you might be thinking, “Well, with the benefit of autoupdaters and model names, do I even need to use composite relationships? Can’t all relationships be simple?” The answer is yes. However, there still is a reason to have composite relationships: performance.