Defaults for Child and This Model Name Fields

There are two more fields that complete the relationship puzzle: FIBERCHILDCLASSMODELNAME and THISFIBERCLASSMODELNAME. As these field names imply, the former holds the model name for the child object and the latter holds the model name for the current object. The following image displays the four fields for the buffer tube, which show THISFIBERCLASSMODELNAME as BufferTube and FIBERCHILDCLASSMODELNAME as FiberStrand:

The fiber children, in this case, would look similar with one important difference: its FIBERCHILDCLASSMODELNAME is null:

The “Child” is null simply because the fiber strand has no children. But, notice its parent is the BufferTube and the tube specific GUID is stored in FIBERPARENT.

Back to the question, if there is not a “child” autoupdater, how are these fields populated? The answer is using default values.

If you look at the feature class or object class properties in ArcCatalog, you can see the default values. For example, the fiber optic cable Feature Class properties lists BUFFERTUBE as the default value for the cable’s FIBERCHILDCLASSMODELNAME. This is simply because buffer tubes are the children of cables.

And, if you look at the F_BUFFERTUBE properties, its FIBERCHILDCLASSMODELNAME is set to FIBERSTRAND. Again, this is simply because buffer tubes’ children are fiber strands.

All of this holds true for the “this” fields as well. Buffer tubes get the default BufferTube for THISFIBERCLASSMODELNAME, fiber strands get the default FiberStrand for THISFIBERCLASSMODELNAME, racks get Rack, patch panels get PatchPanel, and so forth.

Hang in there, we are almost finished, just a few more questions to answer. Why can’t their be a model name to input the “child” class model name fields? How are we supposed to handle parents that have multiple kinds of children? These questions are actually related, and the answer to both involves using the FiberMultiContainer class model name.