Details
-
Bug
-
Resolution: Fixed
-
Major
-
7.1.0
-
None
-
Untriaged
-
1
-
Unknown
Description
This is not too dissimiar to MB-50828, but it entails explicitly closing the iterator half way.
Create a bucket default and insert a few documents:
INSERT INTO default VALUES(uuid(),
{"f1": 1});
INSERT INTO default VALUES(uuid(),
);
INSERT INTO default VALUES(uuid(),
);
INSERT INTO default VALUES(uuid(),
);
INSERT INTO default VALUES(uuid(),
);
INSERT INTO default VALUES(uuid(),
);
....(do it a few hundred times)
create the following javascript function:
function somedml()
{ var q = UPDATE default SET f1 = 2; q.close() }create and execute the UDF:
CREATE FUNCTION somedml() LANGUAGE javascript AS "somedml" AT "test";
EXECUTE FUNCTION dml();
This function updates default, and q.close is a noop..
Now try with a RETURNING clause:
function somedml()
{ var q = UPDATE default SET f1 = 2 RETURNING f1; q.close() }Here, by the time q.close() is called, some documents will have been updates, some will be pending awaiting being pulled from the iterator, and the close() cancels the iterator.
I think the moral here is clear - much like cancelling left over requests and the end of the function should complete pending DML rather than cancelling it, an explicit q.close() should check mutations, and if it is > 0 should complete rather than cancel.
Attachments
For Gerrit Dashboard: MB-50961 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
170679,3 | MB-50961 : Complete DMLs if explicitly close()'ed | unstable | eventing-ee | Status: MERGED | +2 | +1 |
170706,2 | MB-50961: test case for consume with explicit close | master | testrunner | Status: MERGED | +2 | +1 |