[
https://issues.apache.org/jira/browse/HIVE-22728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17033539#comment-17033539
]
Zoltan Haindrich commented on HIVE-22728:
-----------------------------------------
I think we should even consider moving the uniqueness to the table level;
because as of now the users doesn't gain any advantage of the gloablly unique
contraint name; because they may only drop a contraint on a specific table:
{code}
ALTER TABLE numericDataType DROP CONSTRAINT check1;
{code}
dropping {{check1}} on a different table results in an error; so I suppose
constraints do "belong" to tables...
independently from the choosen path there is one more thing which might need to
be addressed: when a contraint violation occurs; the contraint's name is
mentioned in the error message - if it is allowed to use the same name in
different databases; then the error message should make where the constraint
belongs to....(I don't think this would happen frequently; so if it complicates
things a lot - it could be left out)
https://github.com/apache/hive/blob/0d9deba3c15038df4c64ea9b8494d554eb8eea2f/ql/src/test/queries/clientpositive/check_constraint.q#L130
> Limit the scope of uniqueness of constraint name to database
> ------------------------------------------------------------
>
> Key: HIVE-22728
> URL: https://issues.apache.org/jira/browse/HIVE-22728
> Project: Hive
> Issue Type: Wish
> Reporter: Jesus Camacho Rodriguez
> Assignee: Miklos Gergely
> Priority: Major
>
> Currently, constraint names are globally unique across all databases
> (assumption is that this may have done by design). Nevertheless, though
> behavior seems to be implementation specific, it would be interesting to
> limit the scope to uniqueness per database.
> Currently we do not store database information with the constraints. To
> change the scope to one db, we would need to store the DB_ID in the
> KEY_CONSTRAINTS table in metastore when we create a constraint and add the
> DB_ID to the PRIMARY KEY of that table. Some minor changes to the error
> messages would be needed too, since otherwise it would be difficult to
> identify the correct violation in queries that span across multiple
> databases. Additionally, the SQL scripts will need to be updated to populate
> the DB_ID when we upgrade to new version.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
