6
0
mirror of https://github.com/FirebirdSQL/firebird-qa.git synced 2025-01-22 21:43:06 +01:00
firebird-qa/tests/bugs/core_5555_test.py

109 lines
3.3 KiB
Python

#coding:utf-8
#
# id: bugs.core_5555
# title: 3.0 error handling for SELECT WITH LOCK breaks compatibility with 2.5
# decription:
# Checked on:
# 4.0.0.1635 SS: OK, 1.053s.
# 4.0.0.1633 CS: OK, 1.309s.
# 3.0.5.33180 SS: OK, 0.823s.
# 3.0.5.33178 CS: OK, 1.181s.
# See also http://tracker.firebirdsql.org/browse/CORE-4473
#
# tracker_id: CORE-5555
# min_versions: ['3.0.3']
# versions: 3.0.3
# qmid: None
import pytest
from firebird.qa import db_factory, isql_act, Action
# version: 3.0.3
# resources: None
substitutions_1 = []
init_script_1 = """"""
db_1 = db_factory(sql_dialect=3, init=init_script_1)
test_script_1 = """
set list on;
recreate table test(x int, y int);
insert into test(x, y) values(1, 2);
commit;
set transaction no wait;
set term ^;
execute block as
declare c int;
begin
execute statement ('select current_transaction from test where x = ? and 1=1 with lock') (1)
on external 'localhost:' || rdb$get_context('SYSTEM','DB_NAME')
as user 'sysdba' password 'masterkey'
into c;
end
^
execute block returns(gds_on_update int) as
begin
begin
update test set y = -y where x = 1 and 2=2;
when any do
begin
gds_on_update = gdscode;
end
end
suspend;
end
^
execute block returns(gds_on_select_with_lock int) as
declare c int;
begin
begin
select y from test where x = 1 and 3=3 with lock into c;
when any do
begin
gds_on_select_with_lock = gdscode;
end
end
suspend;
end
^
set term ;^
rollback;
-- ||||||||||||||||||||||||||||
-- ###################################||| FB 4.0+, SS and SC |||##############################
-- ||||||||||||||||||||||||||||
-- If we check SS or SC and ExtConnPoolLifeTime > 0 (config parameter FB 4.0+) then current
-- DB (bugs.core_NNNN.fdb) will be 'captured' by firebird.exe process and fbt_run utility
-- will not able to drop this database at the final point of test.
-- Moreover, DB file will be hold until all activity in firebird.exe completed and AFTER this
-- we have to wait for <ExtConnPoolLifeTime> seconds after it (discussion and small test see
-- in the letter to hvlad and dimitr 13.10.2019 11:10).
-- This means that one need to kill all connections to prevent from exception on cleanup phase:
-- SQLCODE: -901 / lock time-out on wait transaction / object <this_test_DB> is in use
-- #############################################################################################
delete from mon$attachments where mon$attachment_id != current_connection;
commit;
"""
act_1 = isql_act('db_1', test_script_1, substitutions=substitutions_1)
expected_stdout_1 = """
GDS_ON_UPDATE 335544336
GDS_ON_SELECT_WITH_LOCK 335544336
"""
@pytest.mark.version('>=3.0.3')
def test_1(act_1: Action):
act_1.expected_stdout = expected_stdout_1
act_1.execute()
assert act_1.clean_expected_stdout == act_1.clean_stdout