Code: Select all
VAR TEST3 BASE INIT(
REL{TUP{ID 1,T "A1",SPLIT1 REL{TUP{CTK 1,STR "B1"},TUP{CTK 2,STR "C1"}}},
TUP{ID 2,T "D2",SPLIT1 REL{TUP{CTK 1,STR "E2"},TUP{CTK 2,STR "G2"},TUP{CTK 3,STR "H2"}}},
TUP{ID 3,T "J3",SPLIT1 REL{TUP{CTK 1,STR "K3"}}}}
)KEY{ID};
//THE INTENT IS TO UPDATE ATTRIBUTE STR IN A SPLIT1 RELATION.
OPERATOR UPDATE.TEST3(ATTR.ID INT,ATTR.CTK INT,ATTR.STR CHAR)RETURNS SAME_TYPE_AS(TEST3);
UPDATE TEST3 WHERE ID=ATTR.ID:{UPDATE SPLIT1 WHERE CTK=ATTR.CTK:{STR:=ATTR.STR}};
RETURN TEST3;
END;
Eventually relvar test3 will have empty split1 relations! If the updates are unique for each execution there doesn't seem to be a problem.
I note that an update via the RelvarEditor for STR IN SPLIT1 is using only 1 tuple (ID) and redefining the SPLIT1 relation for that tuple:
UPDATE TEST3 WHERE ID = 2: {SPLIT1 := RELATION {CTK INTEGER, STR CHARACTER} {
TUPLE {CTK 1, STR 'E2'},
TUPLE {CTK 2, STR 'G222'},
TUPLE {CTK 3, STR 'H2'}}};
I don't see how anything could impair the SPLIT1 relation if it's always defined in its entirety like this.
But in code it would seem impractical to redefine the entire SPLIT1 relation like this. It obviously would
be easier to use the nested update going thru several tuples. I assume this is where the problem is.
stephen