Update anomaly.

This forum is to report technical problems with Rel.
Post Reply
steved
Posts: 49
Joined: Sun Sep 01, 2013 10:53 pm

Update anomaly.

Post by steved »

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;
Run the update operator "2" consecutive times with the "same" values for ATTR.ID, ATTR.CTK AND ATTR.STR.
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
Dave
Site Admin
Posts: 372
Joined: Sun Nov 27, 2005 7:19 pm

Re: Update anomaly.

Post by Dave »

What a strange bug! :shock:

I've managed to duplicate it with a simplified case. Given this:

Code: Select all

VAR TEST4 REAL RELATION {ID INTEGER, RVA RELATION {RID INTEGER, STR CHAR}} KEY {ID};

INSERT TEST4 RELATION {
	TUPLE {ID 1, RVA RELATION {TUPLE {RID 11, STR 'A'}, TUPLE {RID 22, STR 'E'}}},
	TUPLE {ID 2, RVA RELATION {TUPLE {RID 22, STR 'B'}, TUPLE {RID 33, STR 'F'}}},
	TUPLE {ID 3, RVA RELATION {TUPLE {RID 33, STR 'C'}, TUPLE {RID 44, STR 'G'}}},
	TUPLE {ID 4, RVA RELATION {TUPLE {RID 44, STR 'D'}, TUPLE {RID 55, STR 'H'}}}
};
Execute this:

Code: Select all

UPDATE TEST4 WHERE ID = 2: {UPDATE RVA WHERE RID = 22: {STR := 'blah'}};
UPDATE TEST4 WHERE ID = 2: {UPDATE RVA WHERE RID = 22: {STR := 'blah'}};
Instead of winding up with the expected tuple in the RVA relation-valued attribute, it vanishes!

I've added this to my "to do" list.
Post Reply