Quantcast
Channel: SCN: Message List - SAP HANA Developer Center
Viewing all articles
Browse latest Browse all 9165

Re: How to create check constraint in HANA ?

$
0
0

Hi there!

 

Technically you can implement this in different ways, e.g. via a set of database triggers:

createcolumntable sales (client varchar(3) notnull,

                           tx_id bigintprimarykey,

                           what varchar(30),

                           how_much decimal (10,3));

 

drop trigger trg_client_check;

create trigger trg_client_check

AFTERINSERTORUPDATE

on sales

referencing NEW ROWAS NEWROW

for each row

begin

-- set up error message signalling

 

DECLARE curr_client varchar(30) :=  '';

DECLARE WRONG_CLIENT_COND CONDITION FOR SQL_ERROR_CODE 10007;

DECLARE EXIT HANDLER FOR WRONG_CLIENT_COND RESIGNAL;

-- retrieve the currently valid client from the context variable

 

select SESSION_CONTEXT ('CLIENT') as curr_client into curr_client from dummy;

 

if (:newrow.client) <> (:curr_client) then  

 

SIGNAL WRONG_CLIENT_COND SET MESSAGE_TEXT ='Data change only allowed for your own logon client!';

endif;

end;

 

 

select SESSION_CONTEXT ('CLIENT') as curr_client   from dummy;

-- CURR_CLIENT

-- 800       

 

 

insertinto sales values ('999', 2, 'Steeringwheel', 12);

 

-- Started: 2014-02-11 14:16:06

-- Could not execute 'insert into sales values ('999', 2, 'Steeringwheel', 12)' in 105 ms 818 µs .

-- SAP DBTech JDBC: [10007]: user-defined error: user-defined error

 

insertinto sales values ('800', 2, 'Steeringwheel', 12);

-- Started: 2014-02-11 14:23:01

-- Statement 'insert into sales values ('800', 2, 'Steeringwheel', 12)'

-- successfully executed in 171 ms 489 µs  (server processing time: 127 ms 134 µs) - Rows Affected: 1

 

select * from sales

-- CLIENT|TX_ID|WHAT         |HOW_MUCH

-- 800   |2 |Steeringwheel|12.000 

 

 

While this seems to work on this super-simple level it's not what I'd recommend.

Actually, allowing users directly to update/insert/delete on your tables is something I would not want to have.

 

Instead, build stored procedures for that. These stored procedures run in definer security context and can handle all sorts of access check conditions easily without the need to ever expose any of the tables directly to your users.

Basically you would build a data change API on top of your data model - which makes a lot of sense as typically users work with entities or objects and not with records in normalized tables.

 

- Lars



Viewing all articles
Browse latest Browse all 9165

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>