Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id B3D8D200BDB for ; Mon, 12 Dec 2016 09:27:05 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id B26AB160B22; Mon, 12 Dec 2016 08:27:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 08A0C160B0D for ; Mon, 12 Dec 2016 09:27:04 +0100 (CET) Received: (qmail 41356 invoked by uid 500); 12 Dec 2016 08:27:04 -0000 Mailing-List: contact dev-help@atlas.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@atlas.incubator.apache.org Delivered-To: mailing list dev@atlas.incubator.apache.org Received: (qmail 41345 invoked by uid 99); 12 Dec 2016 08:27:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2016 08:27:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 78E641805E4 for ; Mon, 12 Dec 2016 08:27:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -7.019 X-Spam-Level: X-Spam-Status: No, score=-7.019 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id x7FDjMMK6LQ8 for ; Mon, 12 Dec 2016 08:27:02 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with SMTP id B71765F56F for ; Mon, 12 Dec 2016 08:27:01 +0000 (UTC) Received: (qmail 39441 invoked by uid 99); 12 Dec 2016 08:27:00 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Dec 2016 08:27:00 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 1E6292C03E5 for ; Mon, 12 Dec 2016 08:27:00 +0000 (UTC) Date: Mon, 12 Dec 2016 08:27:00 +0000 (UTC) From: "Vimal Sharma (JIRA)" To: dev@atlas.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ATLAS-1318) Atlas Type System does not have DELETE API MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 12 Dec 2016 08:27:05 -0000 [ https://issues.apache.org/jira/browse/ATLAS-1318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15741306#comment-15741306 ] Vimal Sharma commented on ATLAS-1318: ------------------------------------- [~breadpowder] 1) When deleting a type T, the approach would be to delete all the types T_Ref (and all entities of T_Ref as well) which have reference to T. Otherwise for the entities of type T_Ref, there would be a "ghost" reference to a type which doesn't exist. "System" types are guaranteed to not have such references to "Custom" types. So we can relax the criteria 3 for considering DELETION of type T. The earlier suggestion was a "playing it safe" alternative when dealing with System types. So, on DELETE request of a Type T, below steps can be followed: A) Verify whether T is a "Custom" type B) Find all "Custom" types T_Ref which have reference to T C) Remove all entities of type T_Ref D) Remove type T_Ref E) Remove all entities of type T F) Remove type T 2) Please go ahead with adding an optional attribute (maybe "typeKind") to identify whether a type is a "Custom" or "System" type. The types for which this attribute will not be available will be treated as "System" attributes. 3) I am not aware of any direct request to get type hierarchy. We might have to get all the types using call "/api/atlas/types" and then scan for references in "/api/atlas/types/{typeName}" P.S. There is a catch in step B of point 1. What if, for some "Custom" type T_Ref which has reference to T, user forgot to add "Custom" attribute. Now that the type T is removed, there will be "ghost" references to T from T_Ref. One solution is to look for references to T in all types and if any non "Custom" type has reference to T, we should abort the delete. > Atlas Type System does not have DELETE API > ------------------------------------------ > > Key: ATLAS-1318 > URL: https://issues.apache.org/jira/browse/ATLAS-1318 > Project: Atlas > Issue Type: Bug > Affects Versions: 0.7-incubating > Reporter: Zineng Yuan > > I am trying to extend Atlas Type System by adding custom data type. However, when I found a type name was misspecified and needed to be recreated, I can't find a Restful Delete API. > Question is does Atlas expose a Delete API for custom data types/attributes? Without this delete API, it's difficult to rely on Atlas as a meta store to extend custom data. > Please do suggest how to recreate a data type in this case. Thank you! > -- This message was sent by Atlassian JIRA (v6.3.4#6332)