Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 11 Jul 2014 18:00:11 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12726842.1405101386933.25654.1405101611143@arcas>
In-Reply-To: <JIRA.12726842.1405101386933@arcas>
References: <JIRA.12726842.1405101386933@arcas>
Subject: [jira] [Updated] (DERBY-6659) The Reference Guide should state how
 long a SET CONSTRAINTS command is good for
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-6659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas updated DERBY-6659:
---------------------------------

    Description: 
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;

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}


  was:
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}


> 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;
> 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)