Skip to content

Enriched warning message on implicit/explicit commit #371

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 21 commits into from
Jul 20, 2017

Conversation

Pazus
Copy link
Member

@Pazus Pazus commented Jun 27, 2017

Resolves #364

@Pazus Pazus added this to the v3.0.2 milestone Jun 27, 2017
@Pazus Pazus self-assigned this Jun 27, 2017
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.67% when pulling 6f4e760 on Pazus:issue-364 into 65d0169 on utPLSQL:develop.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.67% when pulling 6f4e760 on Pazus:issue-364 into 65d0169 on utPLSQL:develop.

@jgebal
Copy link
Member

jgebal commented Jun 27, 2017

I was thinking of following approach:
In ut_suite_item have start_transaction_id.
The value of that variable would be set when savepoint is created (using DBMS_TRANSACTION.LOCAL_TRANSACTION_ID)
Inside ut_executable we can reference the value of start_transaction_id from the self passed by invoking test/suite.
We could then check in the ut_executeable, after executing block, if transaction id is still the same.
If it's NULL or it is changed, commit/rollback was done.

This way we can identify exactly where the savepoint was broken and provide a proper error/failure/warning message.

I'll ad the same comment to #364.
Let me know what you think.

@coveralls
Copy link

coveralls commented Jun 29, 2017

Coverage Status

Coverage increased (+0.1%) to 91.82% when pulling 16003af on Pazus:issue-364 into 021eead on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 6a2eefb on Pazus:issue-364 into ** on utPLSQL:develop**.

1 similar comment
@coveralls
Copy link

Coverage Status

Changes Unknown when pulling 6a2eefb on Pazus:issue-364 into ** on utPLSQL:develop**.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling dc6ab50 on Pazus:issue-364 into ea2573e on utPLSQL:develop.

1 similar comment
@coveralls
Copy link

coveralls commented Jul 2, 2017

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling dc6ab50 on Pazus:issue-364 into ea2573e on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling 63a1710 on Pazus:issue-364 into 8196046 on utPLSQL:develop.

1 similar comment
@coveralls
Copy link

coveralls commented Jul 3, 2017

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling 63a1710 on Pazus:issue-364 into 8196046 on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling 320d3bd on Pazus:issue-364 into ce2d8ad on utPLSQL:develop.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling 320d3bd on Pazus:issue-364 into ce2d8ad on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling 320d3bd on Pazus:issue-364 into ce2d8ad on utPLSQL:develop.

@coveralls
Copy link

coveralls commented Jul 4, 2017

Coverage Status

Coverage decreased (-0.04%) to 91.68% when pulling 4b63eb4 on Pazus:issue-364 into f92772f on utPLSQL:develop.

@Pazus
Copy link
Member Author

Pazus commented Jul 8, 2017

@jgebal
I started implementation of the requested changes and realized its tricky

if a test has commit, I can find the place of the commit in ut_executables of the test. but then if we has a stacked suites rollback after afterall of the top-level suite will also fail and I dont see a way to propagate the place of commit there...

Do you think we need it? Also several commits might occure, do we need to list them all?

@coveralls
Copy link

coveralls commented Jul 8, 2017

Coverage Status

Coverage decreased (-0.04%) to 91.762% when pulling 0d5a873 on Pazus:issue-364 into eab7ad9 on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.04%) to 91.762% when pulling 5941731 on Pazus:issue-364 into eab7ad9 on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 92.062% when pulling e896c61 on Pazus:issue-364 into 7632d99 on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 92.099% when pulling 4a0dadc on Pazus:issue-364 into f82dcac on utPLSQL:develop.

1 similar comment
@coveralls
Copy link

coveralls commented Jul 15, 2017

Coverage Status

Coverage increased (+0.1%) to 92.099% when pulling 4a0dadc on Pazus:issue-364 into f82dcac on utPLSQL:develop.

@jgebal jgebal modified the milestones: v3.1.0, v3.0.2 Jul 17, 2017
--listener - after call to executable
a_listener.fire_after_event(self.associated_event_name, a_item);

if l_start_transaction_id != dbms_transaction.local_transaction_id(true) then
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you create a new transaction here? I'd compare with null.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If beforetest commits and test commits, we cannot "see" that the test committed as there was no transaction (it was committed at the time we checked).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But then function will return null, we should check for null.

if l_start_transaction_id != dbms_transaction.local_transaction_id Or dbms_transaction.local_transaction_id is null

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, we need to create transaction at the start.
You're right, we don't need to create it at the end, but do an additional null check.
If you think it should be changed, so that we don't create transaction after execution, can you update the PR?
I'm ok with both solutions.

member procedure init(
self in out nocopy ut_suite_item, a_object_owner varchar2, a_object_name varchar2, a_name varchar2,
a_description varchar2, a_path varchar2, a_rollback_type integer, a_disabled_flag boolean),
member procedure set_disabled_flag(self in out nocopy ut_suite_item, a_disabled_flag boolean),
member function get_disabled_flag return boolean,
member function create_savepoint_if_needed return varchar2,
member procedure rollback_to_savepoint(self in out nocopy ut_suite_item, a_savepoint varchar2),
member function get_transaction_invalidators return ut_varchar2_list,
final member procedure add_transaction_invalidator(a_object_name varchar2),
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it final? Don't think the restriction is needed

@@ -78,7 +78,7 @@ create or replace package body ut_annotations as
,'%(' || c_rgexp_identifier || ')'
,modifier => 'i'
,subexpression => 1));
l_annotation_params_str := trim(regexp_substr(l_annotation_str, '\((.*?)\)$', subexpression => 1));
l_annotation_params_str := trim(regexp_substr(l_annotation_str, '\((.*?)\)\s*$', subexpression => 1));
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Important fix! Thanks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could go as a separate PR for traceability

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.613% when pulling 45e1765 on Pazus:issue-364 into 0f2c2d7 on utPLSQL:develop.

1 similar comment
@coveralls
Copy link

coveralls commented Jul 19, 2017

Coverage Status

Coverage increased (+0.1%) to 91.613% when pulling 45e1765 on Pazus:issue-364 into 0f2c2d7 on utPLSQL:develop.

@jgebal jgebal changed the title Enriched warning message is implicit commit issued Enriched warning message if implicit commit issued Jul 20, 2017
@jgebal jgebal changed the title Enriched warning message if implicit commit issued Enriched warning message on implicit/explicit commit Jul 20, 2017
@jgebal
Copy link
Member

jgebal commented Jul 20, 2017

@Pazus
Can you review the existing solution and let me know if it's OK with you?
I think it's fine to spit out all the warnings, even if there is plenty of them.
My reasoning is that developers should fix them and avoid using --%rollback(auto) with transaction controlled tests/code.

@coveralls
Copy link

coveralls commented Jul 20, 2017

Coverage Status

Coverage increased (+0.1%) to 91.613% when pulling 6f555c2 on Pazus:issue-364 into 0f2c2d7 on utPLSQL:develop.

Processed check iа commit occured without starting new trancation
@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.616% when pulling c820b98 on Pazus:issue-364 into 0f2c2d7 on utPLSQL:develop.

1 similar comment
@coveralls
Copy link

coveralls commented Jul 20, 2017

Coverage Status

Coverage increased (+0.1%) to 91.616% when pulling c820b98 on Pazus:issue-364 into 0f2c2d7 on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.616% when pulling 29050fd on Pazus:issue-364 into f5597bb on utPLSQL:develop.

2 similar comments
@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.616% when pulling 29050fd on Pazus:issue-364 into f5597bb on utPLSQL:develop.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.616% when pulling 29050fd on Pazus:issue-364 into f5597bb on utPLSQL:develop.

@jgebal jgebal merged commit 7e47e45 into utPLSQL:develop Jul 20, 2017
@coveralls
Copy link

Coverage Status

Coverage increased (+0.1%) to 91.616% when pulling 8662937 on Pazus:issue-364 into f5597bb on utPLSQL:develop.

1 similar comment
@coveralls
Copy link

coveralls commented Jul 20, 2017

Coverage Status

Coverage increased (+0.1%) to 91.616% when pulling 8662937 on Pazus:issue-364 into f5597bb on utPLSQL:develop.

@Pazus Pazus modified the milestones: v3.0.3, v3.1.0 Aug 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants