You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@atlas.apache.org by Apoorv Naik <an...@hortonworks.com> on 2016/09/13 04:22:51 UTC
Current use cases for POST /entities
Is anyone relying on the definition object within the response of a create entity call ? If not, let’s remove it from the response as it can be inferred from the request body itself and the only useful piece seems to be the GUIDs.
Re: Current use cases for POST /entities
Posted by Dave Kantor <dk...@us.ibm.com>.
Our Atlas consumers needed a way of determining which guids corresponded to
each entity created/updated. To satisfy that requirement, we have added a
new guidMapping field to the response which is exactly what David Radley
suggests: a nested skeleton object structure, where each object in the
structure has a guid, and a references map. The root objects in the
structure correspond to the root objects in the request so callers can
easily navigate the structure. Jeff Hagelberg implemented this solution on
our Atlas fork and will contribute it to the public Atlas in the near
future. There is already a JIRA for this contribution - ATLAS-746 - which
is assigned to Jeff.
Here is a sample json for the guidMapping, showing the three different
types of references Atlas supports - a single-valued reference, array, and
map:
{
"guidMapping": [
{
"guid": "536b8b35-a82a-43c1-b358-d78340911430",
"references": {
"positions": {
"type": "MAP",
"map": {
"receptionist": {
"guid": "348b1b2b-028b-487c-8eda-29433540086e"
},
"janitor": {
"guid": "4fa37d17-c199-4ba8-b8e5-1e7a8a32a626"
}
}
},
"employees": {
"type": "ARRAY",
"array": [
{
"guid": "4fa37d17-c199-4ba8-b8e5-1e7a8a32a626",
"references": {
"department": {
"type": "VALUE",
"value": {
"guid": "536b8b35-a82a-43c1-b358-d78340911430"
}
}
}
},
{
"guid": "348b1b2b-028b-487c-8eda-29433540086e",
"references": {
"department": {
"type": "VALUE",
"value": {
"guid": "536b8b35-a82a-43c1-b358-d78340911430"
}
}
}
}
]
}
}
}
]
}
David Kantor
IBM Software Group
Phone: 978-899-2072 (T/L: 276-2072)
Email: dkantor@us.ibm.com
From: David Radley <da...@uk.ibm.com>
To: dev@atlas.incubator.apache.org
Date: 09/14/2016 03:44 AM
Subject: Re: Current use cases for POST /entities
Hi,
Yes I agree this is reasonable to not send information supplied by the
sender in the create response. If there are multiple objects being created
we need to return a list of containing the new guids
ResournceProvider.createResources already returns lists of guids already
- we would need to ensure that the order was the same as the request, it
might be worth adding a name (ideally fully qualified name) with the guid
for readability and to aid debugging. If there are contained objects that
are created with guids, it would be worth returning a response which
contains the nested object structure, but only containing the guids (and
name) in the object bodies.
With the guids, we could return other useful information like the last
update date and created date. It might be that we introduce a start date
which could also gain the creation date by default. My suggestion would be
to put this sort of response information in a named json object that used
by creates , updates , deletes, gets and is consistently used by all
objects (types, terms , tags entities etc). I would like that this sort of
information should go in a top level object (I notice interface
ResourceDefinition does not contain this information).
all the best, David Radley.
From: Shwetha Shivalingamurthy <ss...@hortonworks.com>
To: "dev@atlas.incubator.apache.org" <de...@atlas.incubator.apache.org>
Date: 14/09/2016 06:13
Subject: Re: Current use cases for POST /entities
We can remove the definition, but I think we should return the guids.
The location in the response header contains the guid. But we should find
a way of returning all the guids created - probably list of locations?
When you change the create API, make sure to change even the update and
delete APIs.
Regards,
Shwetha
On 14/09/16, 3:46 AM, "Suma Shivaprasad" <su...@gmail.com>
wrote:
>+1
>
>On Mon, Sep 12, 2016 at 9:22 PM, Apoorv Naik <an...@hortonworks.com>
>wrote:
>
>> Is anyone relying on the definition object within the response of a
>>create
>> entity call ? If not, let¹s remove it from the response as it can be
>> inferred from the request body itself and the only useful piece seems
>>to be
>> the GUIDs.
>>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Current use cases for POST /entities
Posted by David Radley <da...@uk.ibm.com>.
Hi,
Yes I agree this is reasonable to not send information supplied by the
sender in the create response. If there are multiple objects being created
we need to return a list of containing the new guids
ResournceProvider.createResources already returns lists of guids already
- we would need to ensure that the order was the same as the request, it
might be worth adding a name (ideally fully qualified name) with the guid
for readability and to aid debugging. If there are contained objects that
are created with guids, it would be worth returning a response which
contains the nested object structure, but only containing the guids (and
name) in the object bodies.
With the guids, we could return other useful information like the last
update date and created date. It might be that we introduce a start date
which could also gain the creation date by default. My suggestion would be
to put this sort of response information in a named json object that used
by creates , updates , deletes, gets and is consistently used by all
objects (types, terms , tags entities etc). I would like that this sort of
information should go in a top level object (I notice interface
ResourceDefinition does not contain this information).
all the best, David Radley.
From: Shwetha Shivalingamurthy <ss...@hortonworks.com>
To: "dev@atlas.incubator.apache.org" <de...@atlas.incubator.apache.org>
Date: 14/09/2016 06:13
Subject: Re: Current use cases for POST /entities
We can remove the definition, but I think we should return the guids.
The location in the response header contains the guid. But we should find
a way of returning all the guids created - probably list of locations?
When you change the create API, make sure to change even the update and
delete APIs.
Regards,
Shwetha
On 14/09/16, 3:46 AM, "Suma Shivaprasad" <su...@gmail.com>
wrote:
>+1
>
>On Mon, Sep 12, 2016 at 9:22 PM, Apoorv Naik <an...@hortonworks.com>
>wrote:
>
>> Is anyone relying on the definition object within the response of a
>>create
>> entity call ? If not, let¹s remove it from the response as it can be
>> inferred from the request body itself and the only useful piece seems
>>to be
>> the GUIDs.
>>
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Current use cases for POST /entities
Posted by Shwetha Shivalingamurthy <ss...@hortonworks.com>.
We can remove the definition, but I think we should return the guids.
The location in the response header contains the guid. But we should find
a way of returning all the guids created - probably list of locations?
When you change the create API, make sure to change even the update and
delete APIs.
Regards,
Shwetha
On 14/09/16, 3:46 AM, "Suma Shivaprasad" <su...@gmail.com>
wrote:
>+1
>
>On Mon, Sep 12, 2016 at 9:22 PM, Apoorv Naik <an...@hortonworks.com>
>wrote:
>
>> Is anyone relying on the definition object within the response of a
>>create
>> entity call ? If not, let¹s remove it from the response as it can be
>> inferred from the request body itself and the only useful piece seems
>>to be
>> the GUIDs.
>>
Re: Current use cases for POST /entities
Posted by Suma Shivaprasad <su...@gmail.com>.
+1
On Mon, Sep 12, 2016 at 9:22 PM, Apoorv Naik <an...@hortonworks.com> wrote:
> Is anyone relying on the definition object within the response of a create
> entity call ? If not, let’s remove it from the response as it can be
> inferred from the request body itself and the only useful piece seems to be
> the GUIDs.
>