[
https://issues.apache.org/jira/browse/IGNITE-6293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16158255#comment-16158255
]
Vladimir Ozerov edited comment on IGNITE-6293 at 9/8/17 7:46 AM:
-----------------------------------------------------------------
[~dsetrakyan], there is no need for broadcast even for non-collocated mode. If
referenced value is primary key of another table (which will be the case for
95% users), then we can just lock that primary key in another cache. This way
FK check reduces to enlisting referenced key into transaction.
was (Author: vozerov):
[~dsetrakyan], there is no need for broadcast even for non-collocated mode. If
referenced value is primary key of another table (which will be the case for
95%), then we can just lock that primary key in another cache. This way FK
check reduces to enlisting referenced key into transaction.
> 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)
