<< Click to Display Table of Contents >> Navigation:  »No topics above this level« Resolving Ambiguous Data Type References

This section explains how to deal with ambiguous data type references - when we use data types that are present in two or more accessible models.

Let's introduce another, slightly different Person structure into our TaxBlaster rapidModel. Add the following below TaxFiling:

structure Person

 name : string

 birthday : string

This will cause the structure defined in our shared, common dataModel, to be masked so that we get errors (lots of errors):
 

The masking occurs because all references to Person in our code are unqualified, so they resolve to the definition in the same file instead of the one in the imported, common dataModel.  The resolved definition of Person does not have the same properties as those referenced in our API, so we get errors.

To overcome this problem we need to fully qualify our usages of Person so that the one from our shared dataModel is selected. Let's start with the usage in the PersonObject resource. Currently this is

objectResource PersonObject type Person

Double-click Person to highlight it and use Code Assist to select Person - com.modelsolv.quickstart.CommonDataModel.GeneralTypes.Person from the list.

The first line of our PersonObject resource declaration now looks as follows (and the errors in the PersonObject resource should now disappear):

objectResource PersonObject type com.modelsolv.quickstart.CommonDataModel.GeneralTypes.Person

 
Before we fix the other errors let's make things a bit easier by aliasing our imported data model.

Aliasing our imports

As you can see, RepreZen™ API Studio qualified names can pretty rapidly become rather long-winded. To make things a bit more user-friendly we can use aliasing to shorten the string needed to disambiguate structure usages.  For example the import statement:
 
import com.modelsolv.quickstart.CommonDataModel.GeneralTypes from "CommonDataModel.rapid"

can be aliased like this:
 
import com.modelsolv.quickstart.CommonDataModel.GeneralTypes from "CommonDataModel.rapid" as common

Now we can update PersonObject to use the alias like this:

objectResource PersonObject type common.Person

Fixing the remaining errors

The remaining errors in our model are all in TaxFilingObject, which knows about the Person type indirectly via the reference property in the TaxFiling structure. Once the reference property is also fully qualified, the properties are resolved and the marked errors disappear.

Further masking issues

Although the rapidModel now no longer appears to contain errors, all is not well. We still have references to Person which are resolving incorrectly to the local, as opposed to the imported, type. You can see this if you look at the Diagram View. The PersonCollection has the wrong kind of Person embedded in it:
 

We have already corrected a data type reference in the PersonObject resource, and another one in the TaxFiling structure.  Looking at the diagram, we see an additional resource (PersonCollection)  and an additional structure (Index) that also need correction. If we qualify these usages, again by using the alias we just introduced, then everything slips into place:
 

Note that the local Person structure has now disappeared from view because this is a diagram of our resourceAPI and not a diagram of our dataModel. The diagram, therefore, only shows data types from accessible data models if they are used by the API.

Copyright © 2016 ModelSolv, Inc.  All rights reserved. RepreZen and RAPID-ML are trademarks of ModelSolv, Inc. Swagger is a registered trademark of SmartBear Software, Inc. RepreZen API Studio is not associated with nor endorsed by SmartBear Software, Inc.