Classes2RDB: Create a new integer type for each attribute?

[georghinkel]

I have a problem with the semantics in the Class2RDB example: The first two dataflow elements are as follows:

AllInstances Attributes {
    field attribute
    type Class!Attribute
    target IntegerType
}

NewInstance IntegerType {
    field integerType
    key 'type_Integer'
    type DB!Type
    target IntegerTypeName
}

My understanding is that for each instance of Attribute a new Integer type is created. For me, that doesn't make sense since the integer type should be something that should be there independently of whether or not there are any attributes. What is the semantics here?

[agarciadom]

No, the semantics is that only one Integer type is created - when the first Integer type is created, it is associated with the "type_Integer" key, and later rows just reuse the instance associated with that key.

This is explained in the description:

NewInstance (needed for tasks 1 and 2): evaluates the key expression against
each input tuple and *tests if an instance of the same type was previously created
against the same key* (potentially from another NewInstance step). If it was not,
it will set the field mentioned in instanceField to a new instance of the specified
type and package within the specified model. Otherwise, it will set the same field
to the previously created element.

Another option in this particular case is to make NewInstance runnable with no input rows and just have it produce one row with that IntegerType, then swap the AllInstances and NewInstance steps. However, I wanted to stress the "key decides whether to create or reuse" idea since it's how we achieve something like the ETL equivalents() operation.

[georghinkel]

Ah, ok, then I somehow misunderstand the semantics of the key field. Thanks for the clarification. But the name of the integer type is still reassigned for each attribute, is it?

[agarciadom]

Yes, in this example it would. I realize now that moving NewInstance + SetFeature before AllInstances would have been a good idea, but let's leave it as it is for TTC :-).