[jira] [Comment Edited] (IGNITE-6293) SQL: Support FOREIGN KEY constraint

["Dmitriy Setrakyan (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158041#comment-16158041 ] 

Dmitriy Setrakyan edited comment on IGNITE-6293 at 9/8/17 2:37 AM:
-------------------------------------------------------------------

BTW, we should also take a look at the Spanner syntax, as it has the same semantic as Ignite affinity collocation:
https://opencredo.com/google-spanner-first-look/

Take a look at the INTERLEAVE keyword.


was (Author: dsetrakyan):
BTW, we should also take a look at the Spanner syntax, as it has the same semantic as Ignite affinity collocation:
https://opencredo.com/google-spanner-first-look/

Take a look at the INTERLEAVED keyword.

> SQL: Support FOREIGN KEY constraint
> -----------------------------------
>
>                 Key: IGNITE-6293
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6293
>             Project: Ignite
>          Issue Type: Task
>          Components: sql
>    Affects Versions: 2.1
>            Reporter: Vladimir Ozerov
>
> We need to support {{FOREIGN KEY}} constraint. This is a complex, though achievable thing.
> 1) We need to check constraint during inserts and updates (from both SQL and cache API). 
> 2) We need to support different modes of {{CASCADE}} actions - "remove", "set null". 
> In general case it would require distributed operations, possibly with predicates. However, as a first iteration, it would be enough to support FK only for co-located data. In this case everything could be done locally.
> *Important* 
> Implementation of FK typically depends heavily on underlying MVCC and transaction subsystems. That said, we should implement it after MVCC and transactional SQL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)