[
https://issues.apache.org/jira/browse/USERGRID-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeffrey updated USERGRID-973:
------------------------------
Description:
There are a few challenges developers have with the way that Usergrid uses
attributes within a document:
1) Name - if you put a document in which has a name already, then the name will
be used to access {code}/{o}/{a}/{c}/{name} {code}which is convenient.
However, if I want to change the 'name' attribute of my document then I will
have challenges. One consideration might be to have the reserved-functionality
of the current 'name' field be something like { '_ugmetadata': {'name':
'sparky'}}
2) Continuing on with the _ugmetadata approach we should also consider putting
the UUID there
3) Pluralization can confuse things from a programmatic standpoint. This comes
when I create an entity with a type of 'dogs' and then when I get the entity
back from UG the 'type' will be 'dog'. This can be confusing and we should
discuss how we might be able to avoid this. Nonetheless, it is likely there
will be existing documents with a 'type' attribute. If a developer wants to
store the document in Usergrid but put the document in a differently-named
collection I will have a problem. We should consider moving 'type' as Usergrid
uses it into _ugmedatata.
4) Location - right now if we see a 'location' attribute we require lat and lon
to be in it. Location is also a commonly found attribute and if it is not
intended for Geospatial lookup then a developer must now update their document.
This is a problem.
```
myClass.foo()
```
was:
There are a few challenges developers have with the way that Usergrid uses
attributes within a document:
1) Name - if you put a document in which has a name already, then the name will
be used to access {code}/{o}/{a}/{c}/{name} {code}which is convenient.
However, if I want to change the 'name' attribute of my document then I will
have challenges. One consideration might be to have the reserved-functionality
of the current 'name' field be something like { '_ugmetadata': {'name':
'sparky'}}
2) Continuing on with the _ugmetadata approach we should also consider putting
the UUID there
3) Pluralization can confuse things from a programmatic standpoint. This comes
when I create an entity with a type of 'dogs' and then when I get the entity
back from UG the 'type' will be 'dog'. This can be confusing and we should
discuss how we might be able to avoid this. Nonetheless, it is likely there
will be existing documents with a 'type' attribute. If a developer wants to
store the document in Usergrid but put the document in a differently-named
collection I will have a problem. We should consider moving 'type' as Usergrid
uses it into _ugmedatata.
4) Location - right now if we see a 'location' attribute we require lat and lon
to be in it. Location is also a commonly found attribute and if it is not
intended for Geospatial lookup then a developer must now update their document.
This is a problem.
```java
myClass.foo()
```
> Entity Metadata V2
> ------------------
>
> Key: USERGRID-973
> URL: https://issues.apache.org/jira/browse/USERGRID-973
> Project: Usergrid
> Issue Type: Epic
> Reporter: Jeffrey
>
> There are a few challenges developers have with the way that Usergrid uses
> attributes within a document:
> 1) Name - if you put a document in which has a name already, then the name
> will be used to access {code}/{o}/{a}/{c}/{name} {code}which is convenient.
> However, if I want to change the 'name' attribute of my document then I will
> have challenges. One consideration might be to have the
> reserved-functionality of the current 'name' field be something like {
> '_ugmetadata': {'name': 'sparky'}}
> 2) Continuing on with the _ugmetadata approach we should also consider
> putting the UUID there
> 3) Pluralization can confuse things from a programmatic standpoint. This
> comes when I create an entity with a type of 'dogs' and then when I get the
> entity back from UG the 'type' will be 'dog'. This can be confusing and we
> should discuss how we might be able to avoid this. Nonetheless, it is likely
> there will be existing documents with a 'type' attribute. If a developer
> wants to store the document in Usergrid but put the document in a
> differently-named collection I will have a problem. We should consider
> moving 'type' as Usergrid uses it into _ugmedatata.
> 4) Location - right now if we see a 'location' attribute we require lat and
> lon to be in it. Location is also a commonly found attribute and if it is
> not intended for Geospatial lookup then a developer must now update their
> document. This is a problem.
> ```
> myClass.foo()
> ```
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
