You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Rick Hillegas (JIRA)" <ji...@apache.org> on 2014/07/11 19:58:04 UTC
[jira] [Created] (DERBY-6659) The Reference Guide should state how
long a SET CONSTRAINTS command is good for
Rick Hillegas created DERBY-6659:
------------------------------------
Summary: The Reference Guide should state how long a SET CONSTRAINTS command is good for
Key: DERBY-6659
URL: https://issues.apache.org/jira/browse/DERBY-6659
Project: Derby
Issue Type: Improvement
Components: Documentation
Affects Versions: 10.11.0.0
Reporter: Rick Hillegas
A SET CONSTRAINTS command changes the state of a constraint only until the transaction ends (or another, overriding SET CONSTRAINTS command is issued). Once the transaction ends, the constraint reverts to the default behavior declared for it at CREATE/ALTER TABLE time. However, this behavior is not clear from the reference material on SET CONSTRAINTS: https://builds.apache.org/job/Derby-docs/lastSuccessfulBuild/artifact/trunk/out/ref/rrefsqljsetconstr.html
The following script shows this behavior:
{noformat}
connect 'jdbc:derby:memory:db;create=true' as conn1;
autocommit off;
call syscs_util.syscs_set_database_property( 'derby.locks.waitTimeout', '5' );
commit;
create table tprim
(
keyCol int primary key
);
create table tref
(
refCol int,
constraint refcon foreign key( refCol ) references tprim( keyCol ) deferrable
);
insert into tprim( keyCol ) values ( 1 ), ( 2 ), ( 3 );
commit;
set constraints refcon deferred;
-- succeeds because we switched to deferred mode for this transaction
insert into tref( refCol ) values ( 4 );
rollback;
-- but fails the second time because the end of the previous transaction
-- reverted the refcon constraint to its default (immediate) mode
insert into tref( refCol ) values ( 4 );
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)