You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When I compare two cursors using .join_by the duplicate rows are not detected (I'm attaching an example code).
Provide version info
Oracle Database 23ai Free Release 23.0.0.0.0
utPLSQL version: v3.1.14.4197
NLS: Polish
OS: x86_64/Linux 2.4.xx
Information about client software
Client: SQLDeveloper
To Reproduce
Steps to reproduce the behavior:
Prepare two identical cursors with a column you can join on.
Ensure one of the cursors has an additional row, identical to the ones already present.
Run ut.expect to compare them using .join_by(...).
See a message (via dbms_output) indicating a SUCCESS, yet clearly stating different rowcounts.
Expected behavior
The expectation should result in a FAILURE, not a SUCCESS. The rowcounts are clearly different, so the cursors don't yield the same rows, hence are not equal.
Example code
set serveroutput on
declare
l_actual sys_refcursor;
l_expected sys_refcursor;
begin
open l_expected for
select'FOO' username, 12from dual union allselect'TEST' username, -600 user_id from dual
order by1desc;
open l_actual for
select'FOO' username, 12from dual union allselect'TEST' username, -600 user_id from dual union all-- DUPLICATE!!!select'TEST' username, -600 user_id from dual
order by1asc;
ut.expect( l_actual ).to_equal( l_expected ).join_by('USERNAME');
end;
/--------/* The result is:SUCCESS Actual: refcursor [ count = 3 ] was expected to equal: refcursor [ count = 2 ]*/
The text was updated successfully, but these errors were encountered:
Hmm that's interesting one.
According to
You can join two compound data types by defining join column(s) that will be used to uniquely identify and compare data rows.
But you created scenario where rows cannot be uniquely identified.
@jgebal do you remember what was a intended design?
Sounds like there should be row number added possibly to comparison.
In practice two cursor are different in theory bot sets are same :)
Describe the bug
When I compare two cursors using
.join_by
the duplicate rows are not detected (I'm attaching an example code).Provide version info
Oracle Database 23ai Free Release 23.0.0.0.0
utPLSQL version: v3.1.14.4197
NLS: Polish
OS: x86_64/Linux 2.4.xx
Information about client software
Client: SQLDeveloper
To Reproduce
Steps to reproduce the behavior:
ut.expect
to compare them using.join_by(...)
.dbms_output
) indicating a SUCCESS, yet clearly stating different rowcounts.Expected behavior
The expectation should result in a FAILURE, not a SUCCESS. The rowcounts are clearly different, so the cursors don't yield the same rows, hence are not equal.
Example code
The text was updated successfully, but these errors were encountered: