pathtype Command

• All pathtypes (local and global) can coexist in one database.
• Business types and Relationships can have local pathtypes.
• Local pathtypes cannot have . (dot) in the file name.
• You can reference local pathtypes using AdminTypeName and PathType name separated by a . (dot). This form of local pathtype reference is called a qualified name, for example:
  • T1.cost
  • R1.cost

  By definition, the qualified name for global pathtypes is in the form .pathtypeName. For example, the qualified name for a global pathtype cost will be .cost.

  For unique identification of an admin type by qualified name, qualified names must be unique across Types, Relationships, and global pathtypes with . (dot) in the name.

• Two pathtypes, local or global, with the same name cannot live together in the same hierarchy. For example, type T1 can not have a global pathtype of cost added.
• When adding a local pathtype to a Type/Relationship, the system checks that the qualified name does not conflict with existing local pathtype names in eligible Administrative definitions and global pathtypes.
• Local and global pathtypes with the same name can be of different types.
• Deleting an Administration definition with local pathtypes deletes all local pathtypes belonging to this definition as well.
• In the context of Admin Object Definition or Business Object it is not necessary to use qualified names.
• If there is ambiguity in the pathtypes name interpretation, use qualified names.
• Local PathTypes do not support aliases.

Syntax

add pathtype NAME [ADD_ITEM{Add_ITEM}];

ADD_ITEM provides more information about the pathtype that you are adding:

abstract true|false

attribute NAME {,NAME} 

derived TYPE_NAME

description VALUE 

[!|not] hidden 

owner   | type TYPE_NAME         |
        | relationship REL_NAME |

from ADD_SUB_ITEM {,ADD_SUB_ITEM}

to ADD_SUB_ITEM {,ADD_SUB_ITEM} 

from cardinality | 1   |
                 | one |
				             | many|
                 | n   |

property NAME [value STRING]

property NAME [to ADMINTYPE NAME] [value STRING]

rule NAME

allowservice true|false

ADD_SUB_ITEM is:

type | mod TYPE_NAME {,TYPE_NAME} |
     | all |

relationship |TYPE_NAME [,TYPE_NAME] |
             | all|

ADMIN is:

TYPE NAME

The same pathtype can be defined for use in both business objects and relationships.

The add or mod type NAME pathtype NAME {, NAME} creates an error if you use it to assign a local pathtype to a type. (The same behavior occurs in a relationship.)

It might be more logical to define a local pathtype through the Admin Definitions they belong to, but it is more costly to program this.

Abstract Clause

Abstract pathtypes (abstract is true) cannot be instantiated into a path, therefore abstract pathtypes only add value through inheritance. The pathtype must be global to be used for derivation. You cannot define a pathtype with an owner and abstract set to true.

If you change the abstract value from false to true and paths exist for that pathtype, no error is produced. However, if you try to create a new path from that pathtype, an error displays because it is now abstract and cannot be used for instantiation.

Derived Clause

Use the Derived clause to identify an existing pathtype as the parent of the pathtype you are creating. When using the derived clause to define inheritance, these checks are made:

• The pathtype being derived from must be a global pathtype.
• The "from" Type or Relationship for the child pathtype must support the "is a" relationship with the parent pathtype "from" type of relationship.
• The "to" Type or Relationship for the child pathtype must support the "is a" relationship with the parent "to" type or relationship.

Rule Clause

Pathtypes support rules that define access for read, modify, create, and delete. The paths elements and attributes are governed by the rule that governs the pathtype. When determining access, the app first considers the access to the primary object. If a rule for a policy or state allows access, then the path rule is considered if present.

Path access rules, and any access filters or expression filters are applied to the owning primary objects.

list pathtype [modified after DATE] NAME_PATTERN [SELECT [DUMP [RECORDSEP]]] [tcl] [output FILENAME];

• RECORDSEP is: recordseparator [SEPARATOR_STRING]

The command returns global and local pathtypes when the pathtype is referred to only by name. For example:

list pathtype cost;

Returns:

cost
	I1.cost
	R1.cost
	T1.cost

The global pathtype cost is not displayed with qualified name as .cost.

To list only global pathtypes with name cost, use the where clause.

list pathtype cost where owner=="";
	cost

To list local pathtypes owned by an administration object, use the where clause.

List pathtype * where owner==t2;
            	T2.cost

To list only local pathtypes with name cost:

List pathtype * where owner!="";
	I1.cost
     R1.cost
     T1.cost
	T2.cost

Where Clauses

Where clauses expand the pathtype name to include local pathtypes as well. There are two ways of using pathtype values inside where clauses:

• Where clause contains pathtype[NAME] <op> <value-pattern>. This expression can be converted into efficient SQL. The following conditions are checked:
  • If pathtypes are of different types, the system displays a warning message and the query is not evaluated.
  • If pathtype types are real or integer and the <value-pattern> is a string, which contains dimension and some pathtypes have dimension, while others do not, the system displays a warning message and the query is not evaluated.
  • If pathtype types are real or integer and <value-pattern> is a string, which contains dimension, and pathtype types have different dimensions, a warning message appears and query not evaluated.
• Where clause contains pathtype[NAME].value <op> <value-pattern>. This expression is not converted into efficient SQL. The <value-pattern> from the where clause is evaluated on each object in the result set, and therefore no checking on expanded pathtype type list is done.

For example, when type t1 has local pathtype T1.cost and there is a global pathtype cost with type integer, include the evaluation of the local pathtype for type T1 and global pathtype. For example:

temp query * * * where [pathtype[cost]>15]  

To evaluate the query for local or global pathtype only, use the qualified name of the pathtype. For example, to evaluate the query for global pathtype:

temp query * * * where [pathtype[.cost]>15]

Export of Local Pathtypes

Local pathtypes are exported as part of the owner’s export.

modify pathtype NAME [MOD_ITEM {MOD_ITEM}];

• NAME is the name of the pathtype to modify.
• MOD_ITEM is the type of modification to make. Each is specified in a Modify Pathtype clause, as listed in the following table.

  name NAME

  description VALUE

  icon FILENAME

  [!|not] hidden

  add | attribute NAME | | property NAME to ADMIN [value STRING] | | property NAME [value STRING] | rule NAME |

  remove | attribute NAME | | property NAME to ADMIN | | property NAME | | rule NAME |

  derived TYPE_NAME

  abstract true|false

  property NAME [to ADMINTYPE NAME] [value STRING]

  property NAME [value STRING]

  from MOD_SUB_ITEM {,MOD_SUB_ITEM}

  to MOD_SUB_ITEM {,MOD_SUB_ITEM}

  • MOD_SUB_ITEM is:

    add type TYPE_NAME {,TYPE_NAME}

    add type all

    remove type TYPE_NAME {,TYPE_NAME}

    remove type all

    add relationship RELATIONSHIP_NAME {,RELATIONSHIP_NAME }

    add relationship all

    remove relationship RELATIONSHIP_NAME {,RELATIONSHIP_NAME }

    remove relationship all

You cannot modify the owner modification of the local pathtype. You can modify a global pathtype into a local pathtype if it is in use by no more than a single Administrative definition. However, you cannot modify a local pathtype to become a global pathtype.

Use a qualified name to modify a local pathtype.

When modifying a pathtype, you can add a derived pathtype, but you cannot delete or modify an existing derived pathtype. See Derived Clause.

If you modify the abstract value from false to true and paths exist for that pathtype, no error is produced. However, if you try to create a new path from that pathtype, an error displays because it is now abstract and cannot be used for instantiation.

print pathtype NAME [SELECT][DUMP][tcl][output FILENAME];

• SELECT is: select FIELD_NAME {FIELD_NAME}
  • FIELD_NAME is: SUB_FIELD[.SUB_FIELD{.SUB_FIELD}]
    • SUB_FIELD is: string | string [string]
• DUMP is: dump [SEPARATOR_STRING]
• RECORDSEP is: recordseparator [SEPARATOR_STRING]

In the context of data instance or admin definition, pathtypes display only the pathtype name. For example:

print bus T N R select pathtype;
    pathtype = cost		
print type T1 select pathtype;
    pathtype = cost

In the following examples, pathtype is referred to by name and by qualified name. The following examples return the same value of the local pathtype, cost:

print bus T N R select pathtype[cost]; 
         pathtype[cost] = 1
print bus T N R select pathtype[T.cost];
         pathtype[T.cost] = 1

delete pathtype NAME;

To delete a local pathtype, use the qualified name, such as T1.cost for the local pathtype and cost for the global pathtype. For example:

delete pathtype T1.cost;