You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@usergrid.apache.org by Chris Rogers <ch...@zeta.net> on 2014/07/15 18:40:26 UTC
Using UserGrid for our app
Hello there,
I am creating an application that will require a detailed backend service.
I am browsing to compare the advantages of using a system such as UserGrid
over building something from scratch.
I looked through your documents and became confused about
Connections/Relations and Items, which brought me here. My application may
potentially become large quite quickly, therefore I am looking for a system
that is highly scalable.
My database will require more information than your list of Collections
provide, for example: The User table is going to need relations to other
tables for things such as profile pictures, in-app messaging and locational
information.
My questions are:
- Can you create a collection with any number of properties (within limits
of disk space etc)?
- Can you create relations / joins between multiple collections and narrow
the response time by making queries on top of this join / relation?
Your docs claim there is a way of creating new collections that link via
certain 'verbs' such as 'following' or 'likes'.
This is where I became confused, in order create a relation between 2 sets
of information would I create collections for Profile Pictures, Locations,
Messages etc and link them to User using a structure like (using the verb
'links-to'):
GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
Please let me know if this defeats the point of relational verbs
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris <https://twitter.com/SamJohnAllen>
www.zeta.net
01202 237137
@ZetaAgency <https://twitter.com/ZetaAgency>
Re: Using UserGrid for our app
Posted by Chris Rogers <ch...@zeta.net>.
Dear Usergrid / Apigee,
We have decided to use your system as our client and all is going well for
most platforms. However, for our android application, we have run into a
couple small issues, one of which has been very kindly answered on Stack
Overflow. There is another problem related to updating an entity here:
http://stackoverflow.com/questions/25399676/error-when-updating-apigee-entities
I would really greatly appreciate any help on this subject as it is
puzzling us.
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris <https://twitter.com/SamJohnAllen>
www.zeta.net
01202 237137
@ZetaAgency <https://twitter.com/ZetaAgency>
On 7 August 2014 11:03, Chris Rogers <ch...@zeta.net> wrote:
> Dear Usergrid,
> I am creating an app using Apigee, so far it is going well. But have run
> into a tiny issue with relationship connectors:
>
> - If I create a relationship between 2 entities and wish to retrieve it at
> a later date. Rather than retrieving the whole list of relations, can I
> limit the results by the date they became related?
>
> Thanks in advance
> C
>
>
> Kindest Regards
>
> Chris Rogers
> Digital Developer
> chris@zeta.net
> @portchris <https://twitter.com/SamJohnAllen>
>
>
>
> www.zeta.net
> 01202 237137
> @ZetaAgency <https://twitter.com/ZetaAgency>
>
>
> On 17 July 2014 08:59, Chris Rogers <ch...@zeta.net> wrote:
>
>> Thanks Rod, this makes sense. Thank you for all your help understanding
>> User Grid.
>>
>> Kindest Regards
>>
>> Chris Rogers
>> Digital Developer
>> chris@zeta.net
>> @portchris <https://twitter.com/SamJohnAllen>
>>
>>
>>
>> www.zeta.net
>> 01202 237137
>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>
>>
>> On 16 July 2014 22:13, Rod Simpson <ro...@rodsimpson.com> wrote:
>>
>>> So the name property can’t be a sub object as it is reserved, system
>>> side.
>>>
>>> But you can do something like this:
>>>
>>> POST /dogs {“fullname" : {
>>> "firstname" : "filo",
>>> "lastname" : "rogers"
>>> }
>>> “name”:”fido"
>>> }
>>>
>>>
>>> Then you would do something like this to get it out:
>>>
>>> GET /dogs?ql=select * where fullname.firstname = ‘fido’
>>>
>>> You can only reference the entity directly if it is in the name field
>>> (or whatever is appropriate for the entity type if it is a built-in
>>> collection).
>>>
>>> If you are using the name field, you can do this:
>>>
>>> GET /dogs/fido
>>>
>>>
>>> Rod
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Rod Simpson
>>> @rockerston <https://twitter.com/rockerston>
>>> rodsimpson.com
>>>
>>> On July 16, 2014 at 11:11:04 AM, Chris Rogers (chris@zeta.net) wrote:
>>>
>>> Thanks Rod,
>>>
>>> You have been a great help so cheers for that! I am about 85% certain
>>> that this is the correct approach for me. As I research more I create yet
>>> more questions for myself, but I will keep it short, UserGrids claim "If
>>> you can express it in JSON, we can store it!"
>>>
>>> If I create an object inside an object like so:
>>> POST /dogs {"name" : {
>>> "firstname" : "filo",
>>> "lastname" : "rogers"
>>> }
>>> }
>>>
>>> would I retrieve the information like this:
>>> GET /dogs/name/?ql=select * where "firstname" contains "filo"
>>> Or
>>> GET /dogs/name/firstname/filo
>>>
>>> Many thanks Rod this is an enormous help.
>>>
>>>
>>>
>>> Kindest Regards
>>>
>>> Chris Rogers
>>> Digital Developer
>>> chris@zeta.net
>>> @portchris <https://twitter.com/SamJohnAllen>
>>>
>>>
>>>
>>> www.zeta.net
>>> 01202 237137
>>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>>
>>>
>>> On 16 July 2014 17:48, Rod Simpson <ro...@rodsimpson.com> wrote:
>>>
>>>> Chris,
>>>>
>>>> See answers inline below.
>>>>
>>>> --
>>>> Rod Simpson
>>>> @rockerston <https://twitter.com/rockerston>
>>>> rodsimpson.com
>>>>
>>>> On July 16, 2014 at 2:52:31 AM, Chris Rogers (chris@zeta.net) wrote:
>>>>
>>>> Hey Rod,
>>>> Thank you I hope this project does succeed! And this is perfect! Thank
>>>> you also for the link to the Apigee site, this is very useful.
>>>> Only a couple more questions to clarify and make up my mind:
>>>>
>>>> - Okay you can create relationships up-front and then query those
>>>> relationships, awesome. So (in my mind right now) I am imagining these
>>>> relationships would be made up by including a UserId entity in my Picture
>>>> Collection so that I can link back to my User Collection when I query
>>>> Picture. Is this correct? Or is this more of a SQL / relational database
>>>> way of thinking, and instead the 'verb' links functionality replaces this
>>>> approach?
>>>>
>>>>
>>>> Close. If you had a /pictures collection where you are storing user
>>>> uploads, and those users already exist in the /users collection then what
>>>> you can do is something like this:
>>>>
>>>> POST /users/me/pictures {…picture stuff here…}
>>>>
>>>> This will create the entity in the /pictures collection and create the
>>>> connection between the picture entity and the user in one call.
>>>>
>>>> Then, you can say:
>>>>
>>>> GET /users/me/pictures
>>>>
>>>> And it will return all the connected picture entities.
>>>>
>>>> Optionally, you could do what you suggested - create the user entity,
>>>> create the picture entity, then store the users UUID on the picture entity.
>>>> Then you can do something like this:
>>>>
>>>> GET /pictures?ql=select * where userid=<uuid of user>
>>>>
>>>> This works great if you only have one or two conditions. If you have
>>>> more, then better to use connections.
>>>>
>>>>
>>>>
>>>> - Collections such as User, Devices and Activities are pre-defined with
>>>> entities/properties, so that namespace is taken, but can you extend
>>>> entities/properties of these pre-defined collections as you please?
>>>>
>>>>
>>>> Absolutely. You can add entities to the predefined collections and
>>>> you can add properties to any of these entities. Some collections have
>>>> reserved properties - see the list here:
>>>>
>>>> http://apigee.com/docs/app-services/content/default-data-entities
>>>>
>>>> Most collections use “name” as an additional way to refer to an entity
>>>> (in addition to its UUID). For example:
>>>>
>>>> POST /dogs {“name”:”fido”}
>>>> then
>>>> GET /dogs/fido
>>>>
>>>> but some collections are different (e.g. for /users it is username)
>>>>
>>>>
>>>>
>>>> Many thanks for your time.
>>>>
>>>> Kindest Regards
>>>>
>>>> Chris Rogers
>>>> Digital Developer
>>>> chris@zeta.net
>>>> @portchris <https://twitter.com/SamJohnAllen>
>>>>
>>>>
>>>>
>>>> www.zeta.net
>>>> 01202 237137
>>>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>>>
>>>>
>>>> On 15 July 2014 18:51, Rod Simpson <ro...@rodsimpson.com> wrote:
>>>>
>>>>> Chris,
>>>>>
>>>>> Sounds like an awesome project! See answers inline below:
>>>>>
>>>>> --
>>>>> Rod Simpson
>>>>> @rockerston <https://twitter.com/rockerston>
>>>>> rodsimpson.com
>>>>>
>>>>> On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
>>>>>
>>>>> Hello there,
>>>>> I am creating an application that will require a detailed backend
>>>>> service. I am browsing to compare the advantages of using a system such as
>>>>> UserGrid over building something from scratch.
>>>>>
>>>>> I looked through your documents and became confused about
>>>>> Connections/Relations and Items, which brought me here. My application may
>>>>> potentially become large quite quickly, therefore I am looking for a system
>>>>> that is highly scalable.
>>>>> My database will require more information than your list of
>>>>> Collections provide, for example: The User table is going to need relations
>>>>> to other tables for things such as profile pictures, in-app messaging and
>>>>> locational information.
>>>>>
>>>>> My questions are:
>>>>> - Can you create a collection with any number of properties (within
>>>>> limits of disk space etc)?
>>>>>
>>>>> Collections hold entities, and entities can indeed hold any number
>>>>> of properties. For example, the Dogs collection can have any number of Dog
>>>>> entities, where each dog is a JSON object with properties, sub-objects, or
>>>>> sub-arrays. Basically anything that is supported in JSON can be put in an
>>>>> entity.
>>>>>
>>>>>
>>>>>
>>>>> - Can you create relations / joins between multiple collections and
>>>>> narrow the response time by making queries on top of this join / relation?
>>>>>
>>>>> Absolutely. This is also best practice. We don’t really call
>>>>> them “joins” as this implies a real-time Join like you would see in SQL.
>>>>> But you can indeed create relationships up front and then query those
>>>>> relationships.
>>>>>
>>>>>
>>>>> Your docs claim there is a way of creating new collections that
>>>>> link via certain 'verbs' such as 'following' or 'likes'.
>>>>> This is where I became confused, in order create a relation between 2
>>>>> sets of information would I create collections for Profile Pictures,
>>>>> Locations, Messages etc and link them to User using a structure like (using
>>>>> the verb 'links-to'):
>>>>>
>>>>> GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
>>>>>
>>>>> Please let me know if this defeats the point of relational verbs
>>>>>
>>>>>
>>>>> Yes, you can absolutely do this. We are still in the process of
>>>>> porting a lot of documentation over to the Usergrid website. In the
>>>>> meantime, you can refer to the docs on the Apigee site:
>>>>>
>>>>> http://apigee.com/docs/app-services/content/connecting-users-other-data
>>>>>
>>>>> Everything under the "Apps: Build & Monitor” section should be
>>>>> relevant except the push notifications stuff.
>>>>>
>>>>> Rod
>>>>>
>>>>>
>>>>> Kindest Regards
>>>>>
>>>>> Chris Rogers
>>>>> Digital Developer
>>>>> chris@zeta.net
>>>>> @portchris <https://twitter.com/SamJohnAllen>
>>>>>
>>>>>
>>>>>
>>>>> www.zeta.net
>>>>> 01202 237137
>>>>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
Re: Using UserGrid for our app
Posted by Chris Rogers <ch...@zeta.net>.
Dear Usergrid,
I am creating an app using Apigee, so far it is going well. But have run
into a tiny issue with relationship connectors:
- If I create a relationship between 2 entities and wish to retrieve it at
a later date. Rather than retrieving the whole list of relations, can I
limit the results by the date they became related?
Thanks in advance
C
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris <https://twitter.com/SamJohnAllen>
www.zeta.net
01202 237137
@ZetaAgency <https://twitter.com/ZetaAgency>
On 17 July 2014 08:59, Chris Rogers <ch...@zeta.net> wrote:
> Thanks Rod, this makes sense. Thank you for all your help understanding
> User Grid.
>
> Kindest Regards
>
> Chris Rogers
> Digital Developer
> chris@zeta.net
> @portchris <https://twitter.com/SamJohnAllen>
>
>
>
> www.zeta.net
> 01202 237137
> @ZetaAgency <https://twitter.com/ZetaAgency>
>
>
> On 16 July 2014 22:13, Rod Simpson <ro...@rodsimpson.com> wrote:
>
>> So the name property can’t be a sub object as it is reserved, system side.
>>
>> But you can do something like this:
>>
>> POST /dogs {“fullname" : {
>> "firstname" : "filo",
>> "lastname" : "rogers"
>> }
>> “name”:”fido"
>> }
>>
>>
>> Then you would do something like this to get it out:
>>
>> GET /dogs?ql=select * where fullname.firstname = ‘fido’
>>
>> You can only reference the entity directly if it is in the name field (or
>> whatever is appropriate for the entity type if it is a built-in collection).
>>
>> If you are using the name field, you can do this:
>>
>> GET /dogs/fido
>>
>>
>> Rod
>>
>>
>>
>>
>>
>> --
>> Rod Simpson
>> @rockerston <https://twitter.com/rockerston>
>> rodsimpson.com
>>
>> On July 16, 2014 at 11:11:04 AM, Chris Rogers (chris@zeta.net) wrote:
>>
>> Thanks Rod,
>>
>> You have been a great help so cheers for that! I am about 85% certain
>> that this is the correct approach for me. As I research more I create yet
>> more questions for myself, but I will keep it short, UserGrids claim "If
>> you can express it in JSON, we can store it!"
>>
>> If I create an object inside an object like so:
>> POST /dogs {"name" : {
>> "firstname" : "filo",
>> "lastname" : "rogers"
>> }
>> }
>>
>> would I retrieve the information like this:
>> GET /dogs/name/?ql=select * where "firstname" contains "filo"
>> Or
>> GET /dogs/name/firstname/filo
>>
>> Many thanks Rod this is an enormous help.
>>
>>
>>
>> Kindest Regards
>>
>> Chris Rogers
>> Digital Developer
>> chris@zeta.net
>> @portchris <https://twitter.com/SamJohnAllen>
>>
>>
>>
>> www.zeta.net
>> 01202 237137
>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>
>>
>> On 16 July 2014 17:48, Rod Simpson <ro...@rodsimpson.com> wrote:
>>
>>> Chris,
>>>
>>> See answers inline below.
>>>
>>> --
>>> Rod Simpson
>>> @rockerston <https://twitter.com/rockerston>
>>> rodsimpson.com
>>>
>>> On July 16, 2014 at 2:52:31 AM, Chris Rogers (chris@zeta.net) wrote:
>>>
>>> Hey Rod,
>>> Thank you I hope this project does succeed! And this is perfect! Thank
>>> you also for the link to the Apigee site, this is very useful.
>>> Only a couple more questions to clarify and make up my mind:
>>>
>>> - Okay you can create relationships up-front and then query those
>>> relationships, awesome. So (in my mind right now) I am imagining these
>>> relationships would be made up by including a UserId entity in my Picture
>>> Collection so that I can link back to my User Collection when I query
>>> Picture. Is this correct? Or is this more of a SQL / relational database
>>> way of thinking, and instead the 'verb' links functionality replaces this
>>> approach?
>>>
>>>
>>> Close. If you had a /pictures collection where you are storing user
>>> uploads, and those users already exist in the /users collection then what
>>> you can do is something like this:
>>>
>>> POST /users/me/pictures {…picture stuff here…}
>>>
>>> This will create the entity in the /pictures collection and create the
>>> connection between the picture entity and the user in one call.
>>>
>>> Then, you can say:
>>>
>>> GET /users/me/pictures
>>>
>>> And it will return all the connected picture entities.
>>>
>>> Optionally, you could do what you suggested - create the user entity,
>>> create the picture entity, then store the users UUID on the picture entity.
>>> Then you can do something like this:
>>>
>>> GET /pictures?ql=select * where userid=<uuid of user>
>>>
>>> This works great if you only have one or two conditions. If you have
>>> more, then better to use connections.
>>>
>>>
>>>
>>> - Collections such as User, Devices and Activities are pre-defined with
>>> entities/properties, so that namespace is taken, but can you extend
>>> entities/properties of these pre-defined collections as you please?
>>>
>>>
>>> Absolutely. You can add entities to the predefined collections and
>>> you can add properties to any of these entities. Some collections have
>>> reserved properties - see the list here:
>>>
>>> http://apigee.com/docs/app-services/content/default-data-entities
>>>
>>> Most collections use “name” as an additional way to refer to an entity
>>> (in addition to its UUID). For example:
>>>
>>> POST /dogs {“name”:”fido”}
>>> then
>>> GET /dogs/fido
>>>
>>> but some collections are different (e.g. for /users it is username)
>>>
>>>
>>>
>>> Many thanks for your time.
>>>
>>> Kindest Regards
>>>
>>> Chris Rogers
>>> Digital Developer
>>> chris@zeta.net
>>> @portchris <https://twitter.com/SamJohnAllen>
>>>
>>>
>>>
>>> www.zeta.net
>>> 01202 237137
>>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>>
>>>
>>> On 15 July 2014 18:51, Rod Simpson <ro...@rodsimpson.com> wrote:
>>>
>>>> Chris,
>>>>
>>>> Sounds like an awesome project! See answers inline below:
>>>>
>>>> --
>>>> Rod Simpson
>>>> @rockerston <https://twitter.com/rockerston>
>>>> rodsimpson.com
>>>>
>>>> On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
>>>>
>>>> Hello there,
>>>> I am creating an application that will require a detailed backend
>>>> service. I am browsing to compare the advantages of using a system such as
>>>> UserGrid over building something from scratch.
>>>>
>>>> I looked through your documents and became confused about
>>>> Connections/Relations and Items, which brought me here. My application may
>>>> potentially become large quite quickly, therefore I am looking for a system
>>>> that is highly scalable.
>>>> My database will require more information than your list of Collections
>>>> provide, for example: The User table is going to need relations to other
>>>> tables for things such as profile pictures, in-app messaging and locational
>>>> information.
>>>>
>>>> My questions are:
>>>> - Can you create a collection with any number of properties (within
>>>> limits of disk space etc)?
>>>>
>>>> Collections hold entities, and entities can indeed hold any number of
>>>> properties. For example, the Dogs collection can have any number of Dog
>>>> entities, where each dog is a JSON object with properties, sub-objects, or
>>>> sub-arrays. Basically anything that is supported in JSON can be put in an
>>>> entity.
>>>>
>>>>
>>>>
>>>> - Can you create relations / joins between multiple collections and
>>>> narrow the response time by making queries on top of this join / relation?
>>>>
>>>> Absolutely. This is also best practice. We don’t really call them
>>>> “joins” as this implies a real-time Join like you would see in SQL. But
>>>> you can indeed create relationships up front and then query those
>>>> relationships.
>>>>
>>>>
>>>> Your docs claim there is a way of creating new collections that link
>>>> via certain 'verbs' such as 'following' or 'likes'.
>>>> This is where I became confused, in order create a relation between 2
>>>> sets of information would I create collections for Profile Pictures,
>>>> Locations, Messages etc and link them to User using a structure like (using
>>>> the verb 'links-to'):
>>>>
>>>> GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
>>>>
>>>> Please let me know if this defeats the point of relational verbs
>>>>
>>>>
>>>> Yes, you can absolutely do this. We are still in the process of
>>>> porting a lot of documentation over to the Usergrid website. In the
>>>> meantime, you can refer to the docs on the Apigee site:
>>>>
>>>> http://apigee.com/docs/app-services/content/connecting-users-other-data
>>>>
>>>> Everything under the "Apps: Build & Monitor” section should be relevant
>>>> except the push notifications stuff.
>>>>
>>>> Rod
>>>>
>>>>
>>>> Kindest Regards
>>>>
>>>> Chris Rogers
>>>> Digital Developer
>>>> chris@zeta.net
>>>> @portchris <https://twitter.com/SamJohnAllen>
>>>>
>>>>
>>>>
>>>> www.zeta.net
>>>> 01202 237137
>>>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>>>
>>>>
>>>
>>>
>>
>
Re: Using UserGrid for our app
Posted by Chris Rogers <ch...@zeta.net>.
Thanks Rod, this makes sense. Thank you for all your help understanding
User Grid.
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris <https://twitter.com/SamJohnAllen>
www.zeta.net
01202 237137
@ZetaAgency <https://twitter.com/ZetaAgency>
On 16 July 2014 22:13, Rod Simpson <ro...@rodsimpson.com> wrote:
> So the name property can’t be a sub object as it is reserved, system side.
>
> But you can do something like this:
>
> POST /dogs {“fullname" : {
> "firstname" : "filo",
> "lastname" : "rogers"
> }
> “name”:”fido"
> }
>
>
> Then you would do something like this to get it out:
>
> GET /dogs?ql=select * where fullname.firstname = ‘fido’
>
> You can only reference the entity directly if it is in the name field (or
> whatever is appropriate for the entity type if it is a built-in collection).
>
> If you are using the name field, you can do this:
>
> GET /dogs/fido
>
>
> Rod
>
>
>
>
>
> --
> Rod Simpson
> @rockerston <https://twitter.com/rockerston>
> rodsimpson.com
>
> On July 16, 2014 at 11:11:04 AM, Chris Rogers (chris@zeta.net) wrote:
>
> Thanks Rod,
>
> You have been a great help so cheers for that! I am about 85% certain that
> this is the correct approach for me. As I research more I create yet more
> questions for myself, but I will keep it short, UserGrids claim "If you can
> express it in JSON, we can store it!"
>
> If I create an object inside an object like so:
> POST /dogs {"name" : {
> "firstname" : "filo",
> "lastname" : "rogers"
> }
> }
>
> would I retrieve the information like this:
> GET /dogs/name/?ql=select * where "firstname" contains "filo"
> Or
> GET /dogs/name/firstname/filo
>
> Many thanks Rod this is an enormous help.
>
>
>
> Kindest Regards
>
> Chris Rogers
> Digital Developer
> chris@zeta.net
> @portchris <https://twitter.com/SamJohnAllen>
>
>
>
> www.zeta.net
> 01202 237137
> @ZetaAgency <https://twitter.com/ZetaAgency>
>
>
> On 16 July 2014 17:48, Rod Simpson <ro...@rodsimpson.com> wrote:
>
>> Chris,
>>
>> See answers inline below.
>>
>> --
>> Rod Simpson
>> @rockerston <https://twitter.com/rockerston>
>> rodsimpson.com
>>
>> On July 16, 2014 at 2:52:31 AM, Chris Rogers (chris@zeta.net) wrote:
>>
>> Hey Rod,
>> Thank you I hope this project does succeed! And this is perfect! Thank
>> you also for the link to the Apigee site, this is very useful.
>> Only a couple more questions to clarify and make up my mind:
>>
>> - Okay you can create relationships up-front and then query those
>> relationships, awesome. So (in my mind right now) I am imagining these
>> relationships would be made up by including a UserId entity in my Picture
>> Collection so that I can link back to my User Collection when I query
>> Picture. Is this correct? Or is this more of a SQL / relational database
>> way of thinking, and instead the 'verb' links functionality replaces this
>> approach?
>>
>>
>> Close. If you had a /pictures collection where you are storing user
>> uploads, and those users already exist in the /users collection then what
>> you can do is something like this:
>>
>> POST /users/me/pictures {…picture stuff here…}
>>
>> This will create the entity in the /pictures collection and create the
>> connection between the picture entity and the user in one call.
>>
>> Then, you can say:
>>
>> GET /users/me/pictures
>>
>> And it will return all the connected picture entities.
>>
>> Optionally, you could do what you suggested - create the user entity,
>> create the picture entity, then store the users UUID on the picture entity.
>> Then you can do something like this:
>>
>> GET /pictures?ql=select * where userid=<uuid of user>
>>
>> This works great if you only have one or two conditions. If you have
>> more, then better to use connections.
>>
>>
>>
>> - Collections such as User, Devices and Activities are pre-defined with
>> entities/properties, so that namespace is taken, but can you extend
>> entities/properties of these pre-defined collections as you please?
>>
>>
>> Absolutely. You can add entities to the predefined collections and you
>> can add properties to any of these entities. Some collections have reserved
>> properties - see the list here:
>>
>> http://apigee.com/docs/app-services/content/default-data-entities
>>
>> Most collections use “name” as an additional way to refer to an entity
>> (in addition to its UUID). For example:
>>
>> POST /dogs {“name”:”fido”}
>> then
>> GET /dogs/fido
>>
>> but some collections are different (e.g. for /users it is username)
>>
>>
>>
>> Many thanks for your time.
>>
>> Kindest Regards
>>
>> Chris Rogers
>> Digital Developer
>> chris@zeta.net
>> @portchris <https://twitter.com/SamJohnAllen>
>>
>>
>>
>> www.zeta.net
>> 01202 237137
>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>
>>
>> On 15 July 2014 18:51, Rod Simpson <ro...@rodsimpson.com> wrote:
>>
>>> Chris,
>>>
>>> Sounds like an awesome project! See answers inline below:
>>>
>>> --
>>> Rod Simpson
>>> @rockerston <https://twitter.com/rockerston>
>>> rodsimpson.com
>>>
>>> On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
>>>
>>> Hello there,
>>> I am creating an application that will require a detailed backend
>>> service. I am browsing to compare the advantages of using a system such as
>>> UserGrid over building something from scratch.
>>>
>>> I looked through your documents and became confused about
>>> Connections/Relations and Items, which brought me here. My application may
>>> potentially become large quite quickly, therefore I am looking for a system
>>> that is highly scalable.
>>> My database will require more information than your list of Collections
>>> provide, for example: The User table is going to need relations to other
>>> tables for things such as profile pictures, in-app messaging and locational
>>> information.
>>>
>>> My questions are:
>>> - Can you create a collection with any number of properties (within
>>> limits of disk space etc)?
>>>
>>> Collections hold entities, and entities can indeed hold any number of
>>> properties. For example, the Dogs collection can have any number of Dog
>>> entities, where each dog is a JSON object with properties, sub-objects, or
>>> sub-arrays. Basically anything that is supported in JSON can be put in an
>>> entity.
>>>
>>>
>>>
>>> - Can you create relations / joins between multiple collections and
>>> narrow the response time by making queries on top of this join / relation?
>>>
>>> Absolutely. This is also best practice. We don’t really call them
>>> “joins” as this implies a real-time Join like you would see in SQL. But
>>> you can indeed create relationships up front and then query those
>>> relationships.
>>>
>>>
>>> Your docs claim there is a way of creating new collections that link
>>> via certain 'verbs' such as 'following' or 'likes'.
>>> This is where I became confused, in order create a relation between 2
>>> sets of information would I create collections for Profile Pictures,
>>> Locations, Messages etc and link them to User using a structure like (using
>>> the verb 'links-to'):
>>>
>>> GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
>>>
>>> Please let me know if this defeats the point of relational verbs
>>>
>>>
>>> Yes, you can absolutely do this. We are still in the process of
>>> porting a lot of documentation over to the Usergrid website. In the
>>> meantime, you can refer to the docs on the Apigee site:
>>>
>>> http://apigee.com/docs/app-services/content/connecting-users-other-data
>>>
>>> Everything under the "Apps: Build & Monitor” section should be relevant
>>> except the push notifications stuff.
>>>
>>> Rod
>>>
>>>
>>> Kindest Regards
>>>
>>> Chris Rogers
>>> Digital Developer
>>> chris@zeta.net
>>> @portchris <https://twitter.com/SamJohnAllen>
>>>
>>>
>>>
>>> www.zeta.net
>>> 01202 237137
>>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>>
>>>
>>
>>
>
Re: Using UserGrid for our app
Posted by Rod Simpson <ro...@rodsimpson.com>.
So the name property can’t be a sub object as it is reserved, system side.
But you can do something like this:
POST /dogs {“fullname" : {
"firstname" : "filo",
"lastname" : "rogers"
}
“name”:”fido"
}
Then you would do something like this to get it out:
GET /dogs?ql=select * where fullname.firstname = ‘fido’
You can only reference the entity directly if it is in the name field (or whatever is appropriate for the entity type if it is a built-in collection).
If you are using the name field, you can do this:
GET /dogs/fido
Rod
--
Rod Simpson
@rockerston
rodsimpson.com
On July 16, 2014 at 11:11:04 AM, Chris Rogers (chris@zeta.net) wrote:
Thanks Rod,
You have been a great help so cheers for that! I am about 85% certain that this is the correct approach for me. As I research more I create yet more questions for myself, but I will keep it short, UserGrids claim "If you can express it in JSON, we can store it!"
If I create an object inside an object like so:
POST /dogs {"name" : {
"firstname" : "filo",
"lastname" : "rogers"
}
}
would I retrieve the information like this:
GET /dogs/name/?ql=select * where "firstname" contains "filo"
Or
GET /dogs/name/firstname/filo
Many thanks Rod this is an enormous help.
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris
www.zeta.net
01202 237137
@ZetaAgency
On 16 July 2014 17:48, Rod Simpson <ro...@rodsimpson.com> wrote:
Chris,
See answers inline below.
--
Rod Simpson
@rockerston
rodsimpson.com
On July 16, 2014 at 2:52:31 AM, Chris Rogers (chris@zeta.net) wrote:
Hey Rod,
Thank you I hope this project does succeed! And this is perfect! Thank you also for the link to the Apigee site, this is very useful.
Only a couple more questions to clarify and make up my mind:
- Okay you can create relationships up-front and then query those relationships, awesome. So (in my mind right now) I am imagining these relationships would be made up by including a UserId entity in my Picture Collection so that I can link back to my User Collection when I query Picture. Is this correct? Or is this more of a SQL / relational database way of thinking, and instead the 'verb' links functionality replaces this approach?
Close. If you had a /pictures collection where you are storing user uploads, and those users already exist in the /users collection then what you can do is something like this:
POST /users/me/pictures {…picture stuff here…}
This will create the entity in the /pictures collection and create the connection between the picture entity and the user in one call.
Then, you can say:
GET /users/me/pictures
And it will return all the connected picture entities.
Optionally, you could do what you suggested - create the user entity, create the picture entity, then store the users UUID on the picture entity. Then you can do something like this:
GET /pictures?ql=select * where userid=<uuid of user>
This works great if you only have one or two conditions. If you have more, then better to use connections.
- Collections such as User, Devices and Activities are pre-defined with entities/properties, so that namespace is taken, but can you extend entities/properties of these pre-defined collections as you please?
Absolutely. You can add entities to the predefined collections and you can add properties to any of these entities. Some collections have reserved properties - see the list here:
http://apigee.com/docs/app-services/content/default-data-entities
Most collections use “name” as an additional way to refer to an entity (in addition to its UUID). For example:
POST /dogs {“name”:”fido”}
then
GET /dogs/fido
but some collections are different (e.g. for /users it is username)
Many thanks for your time.
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris
www.zeta.net
01202 237137
@ZetaAgency
On 15 July 2014 18:51, Rod Simpson <ro...@rodsimpson.com> wrote:
Chris,
Sounds like an awesome project! See answers inline below:
--
Rod Simpson
@rockerston
rodsimpson.com
On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
Hello there,
I am creating an application that will require a detailed backend service. I am browsing to compare the advantages of using a system such as UserGrid over building something from scratch.
I looked through your documents and became confused about Connections/Relations and Items, which brought me here. My application may potentially become large quite quickly, therefore I am looking for a system that is highly scalable.
My database will require more information than your list of Collections provide, for example: The User table is going to need relations to other tables for things such as profile pictures, in-app messaging and locational information.
My questions are:
- Can you create a collection with any number of properties (within limits of disk space etc)?
Collections hold entities, and entities can indeed hold any number of properties. For example, the Dogs collection can have any number of Dog entities, where each dog is a JSON object with properties, sub-objects, or sub-arrays. Basically anything that is supported in JSON can be put in an entity.
- Can you create relations / joins between multiple collections and narrow the response time by making queries on top of this join / relation?
Absolutely. This is also best practice. We don’t really call them “joins” as this implies a real-time Join like you would see in SQL. But you can indeed create relationships up front and then query those relationships.
Your docs claim there is a way of creating new collections that link via certain 'verbs' such as 'following' or 'likes'.
This is where I became confused, in order create a relation between 2 sets of information would I create collections for Profile Pictures, Locations, Messages etc and link them to User using a structure like (using the verb 'links-to'):
GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
Please let me know if this defeats the point of relational verbs
Yes, you can absolutely do this. We are still in the process of porting a lot of documentation over to the Usergrid website. In the meantime, you can refer to the docs on the Apigee site:
http://apigee.com/docs/app-services/content/connecting-users-other-data
Everything under the "Apps: Build & Monitor” section should be relevant except the push notifications stuff.
Rod
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris
www.zeta.net
01202 237137
@ZetaAgency
Re: Using UserGrid for our app
Posted by Chris Rogers <ch...@zeta.net>.
Thanks Rod,
You have been a great help so cheers for that! I am about 85% certain that
this is the correct approach for me. As I research more I create yet more
questions for myself, but I will keep it short, UserGrids claim "If you can
express it in JSON, we can store it!"
If I create an object inside an object like so:
POST /dogs {"name" : {
"firstname" : "filo",
"lastname" : "rogers"
}
}
would I retrieve the information like this:
GET /dogs/name/?ql=select * where "firstname" contains "filo"
Or
GET /dogs/name/firstname/filo
Many thanks Rod this is an enormous help.
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris <https://twitter.com/SamJohnAllen>
www.zeta.net
01202 237137
@ZetaAgency <https://twitter.com/ZetaAgency>
On 16 July 2014 17:48, Rod Simpson <ro...@rodsimpson.com> wrote:
> Chris,
>
> See answers inline below.
>
> --
> Rod Simpson
> @rockerston <https://twitter.com/rockerston>
> rodsimpson.com
>
> On July 16, 2014 at 2:52:31 AM, Chris Rogers (chris@zeta.net) wrote:
>
> Hey Rod,
> Thank you I hope this project does succeed! And this is perfect! Thank you
> also for the link to the Apigee site, this is very useful.
> Only a couple more questions to clarify and make up my mind:
>
> - Okay you can create relationships up-front and then query those
> relationships, awesome. So (in my mind right now) I am imagining these
> relationships would be made up by including a UserId entity in my Picture
> Collection so that I can link back to my User Collection when I query
> Picture. Is this correct? Or is this more of a SQL / relational database
> way of thinking, and instead the 'verb' links functionality replaces this
> approach?
>
>
> Close. If you had a /pictures collection where you are storing user
> uploads, and those users already exist in the /users collection then what
> you can do is something like this:
>
> POST /users/me/pictures {…picture stuff here…}
>
> This will create the entity in the /pictures collection and create the
> connection between the picture entity and the user in one call.
>
> Then, you can say:
>
> GET /users/me/pictures
>
> And it will return all the connected picture entities.
>
> Optionally, you could do what you suggested - create the user entity,
> create the picture entity, then store the users UUID on the picture entity.
> Then you can do something like this:
>
> GET /pictures?ql=select * where userid=<uuid of user>
>
> This works great if you only have one or two conditions. If you have
> more, then better to use connections.
>
>
>
> - Collections such as User, Devices and Activities are pre-defined with
> entities/properties, so that namespace is taken, but can you extend
> entities/properties of these pre-defined collections as you please?
>
>
> Absolutely. You can add entities to the predefined collections and you
> can add properties to any of these entities. Some collections have reserved
> properties - see the list here:
>
> http://apigee.com/docs/app-services/content/default-data-entities
>
> Most collections use “name” as an additional way to refer to an entity (in
> addition to its UUID). For example:
>
> POST /dogs {“name”:”fido”}
> then
> GET /dogs/fido
>
> but some collections are different (e.g. for /users it is username)
>
>
>
> Many thanks for your time.
>
> Kindest Regards
>
> Chris Rogers
> Digital Developer
> chris@zeta.net
> @portchris <https://twitter.com/SamJohnAllen>
>
>
>
> www.zeta.net
> 01202 237137
> @ZetaAgency <https://twitter.com/ZetaAgency>
>
>
> On 15 July 2014 18:51, Rod Simpson <ro...@rodsimpson.com> wrote:
>
>> Chris,
>>
>> Sounds like an awesome project! See answers inline below:
>>
>> --
>> Rod Simpson
>> @rockerston <https://twitter.com/rockerston>
>> rodsimpson.com
>>
>> On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
>>
>> Hello there,
>> I am creating an application that will require a detailed backend
>> service. I am browsing to compare the advantages of using a system such as
>> UserGrid over building something from scratch.
>>
>> I looked through your documents and became confused about
>> Connections/Relations and Items, which brought me here. My application may
>> potentially become large quite quickly, therefore I am looking for a system
>> that is highly scalable.
>> My database will require more information than your list of Collections
>> provide, for example: The User table is going to need relations to other
>> tables for things such as profile pictures, in-app messaging and locational
>> information.
>>
>> My questions are:
>> - Can you create a collection with any number of properties (within
>> limits of disk space etc)?
>>
>> Collections hold entities, and entities can indeed hold any number of
>> properties. For example, the Dogs collection can have any number of Dog
>> entities, where each dog is a JSON object with properties, sub-objects, or
>> sub-arrays. Basically anything that is supported in JSON can be put in an
>> entity.
>>
>>
>>
>> - Can you create relations / joins between multiple collections and
>> narrow the response time by making queries on top of this join / relation?
>>
>> Absolutely. This is also best practice. We don’t really call them
>> “joins” as this implies a real-time Join like you would see in SQL. But
>> you can indeed create relationships up front and then query those
>> relationships.
>>
>>
>> Your docs claim there is a way of creating new collections that link via
>> certain 'verbs' such as 'following' or 'likes'.
>> This is where I became confused, in order create a relation between 2
>> sets of information would I create collections for Profile Pictures,
>> Locations, Messages etc and link them to User using a structure like (using
>> the verb 'links-to'):
>>
>> GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
>>
>> Please let me know if this defeats the point of relational verbs
>>
>>
>> Yes, you can absolutely do this. We are still in the process of porting a
>> lot of documentation over to the Usergrid website. In the meantime, you
>> can refer to the docs on the Apigee site:
>>
>> http://apigee.com/docs/app-services/content/connecting-users-other-data
>>
>> Everything under the "Apps: Build & Monitor” section should be relevant
>> except the push notifications stuff.
>>
>> Rod
>>
>>
>> Kindest Regards
>>
>> Chris Rogers
>> Digital Developer
>> chris@zeta.net
>> @portchris <https://twitter.com/SamJohnAllen>
>>
>>
>>
>> www.zeta.net
>> 01202 237137
>> @ZetaAgency <https://twitter.com/ZetaAgency>
>>
>>
>
>
Re: Using UserGrid for our app
Posted by Rod Simpson <ro...@rodsimpson.com>.
Chris,
See answers inline below.
--
Rod Simpson
@rockerston
rodsimpson.com
On July 16, 2014 at 2:52:31 AM, Chris Rogers (chris@zeta.net) wrote:
Hey Rod,
Thank you I hope this project does succeed! And this is perfect! Thank you also for the link to the Apigee site, this is very useful.
Only a couple more questions to clarify and make up my mind:
- Okay you can create relationships up-front and then query those relationships, awesome. So (in my mind right now) I am imagining these relationships would be made up by including a UserId entity in my Picture Collection so that I can link back to my User Collection when I query Picture. Is this correct? Or is this more of a SQL / relational database way of thinking, and instead the 'verb' links functionality replaces this approach?
Close. If you had a /pictures collection where you are storing user uploads, and those users already exist in the /users collection then what you can do is something like this:
POST /users/me/pictures {…picture stuff here…}
This will create the entity in the /pictures collection and create the connection between the picture entity and the user in one call.
Then, you can say:
GET /users/me/pictures
And it will return all the connected picture entities.
Optionally, you could do what you suggested - create the user entity, create the picture entity, then store the users UUID on the picture entity. Then you can do something like this:
GET /pictures?ql=select * where userid=<uuid of user>
This works great if you only have one or two conditions. If you have more, then better to use connections.
- Collections such as User, Devices and Activities are pre-defined with entities/properties, so that namespace is taken, but can you extend entities/properties of these pre-defined collections as you please?
Absolutely. You can add entities to the predefined collections and you can add properties to any of these entities. Some collections have reserved properties - see the list here:
http://apigee.com/docs/app-services/content/default-data-entities
Most collections use “name” as an additional way to refer to an entity (in addition to its UUID). For example:
POST /dogs {“name”:”fido”}
then
GET /dogs/fido
but some collections are different (e.g. for /users it is username)
Many thanks for your time.
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris
www.zeta.net
01202 237137
@ZetaAgency
On 15 July 2014 18:51, Rod Simpson <ro...@rodsimpson.com> wrote:
Chris,
Sounds like an awesome project! See answers inline below:
--
Rod Simpson
@rockerston
rodsimpson.com
On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
Hello there,
I am creating an application that will require a detailed backend service. I am browsing to compare the advantages of using a system such as UserGrid over building something from scratch.
I looked through your documents and became confused about Connections/Relations and Items, which brought me here. My application may potentially become large quite quickly, therefore I am looking for a system that is highly scalable.
My database will require more information than your list of Collections provide, for example: The User table is going to need relations to other tables for things such as profile pictures, in-app messaging and locational information.
My questions are:
- Can you create a collection with any number of properties (within limits of disk space etc)?
Collections hold entities, and entities can indeed hold any number of properties. For example, the Dogs collection can have any number of Dog entities, where each dog is a JSON object with properties, sub-objects, or sub-arrays. Basically anything that is supported in JSON can be put in an entity.
- Can you create relations / joins between multiple collections and narrow the response time by making queries on top of this join / relation?
Absolutely. This is also best practice. We don’t really call them “joins” as this implies a real-time Join like you would see in SQL. But you can indeed create relationships up front and then query those relationships.
Your docs claim there is a way of creating new collections that link via certain 'verbs' such as 'following' or 'likes'.
This is where I became confused, in order create a relation between 2 sets of information would I create collections for Profile Pictures, Locations, Messages etc and link them to User using a structure like (using the verb 'links-to'):
GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
Please let me know if this defeats the point of relational verbs
Yes, you can absolutely do this. We are still in the process of porting a lot of documentation over to the Usergrid website. In the meantime, you can refer to the docs on the Apigee site:
http://apigee.com/docs/app-services/content/connecting-users-other-data
Everything under the "Apps: Build & Monitor” section should be relevant except the push notifications stuff.
Rod
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris
www.zeta.net
01202 237137
@ZetaAgency
Re: Using UserGrid for our app
Posted by Chris Rogers <ch...@zeta.net>.
Hey Rod,
Thank you I hope this project does succeed! And this is perfect! Thank you
also for the link to the Apigee site, this is very useful.
Only a couple more questions to clarify and make up my mind:
- Okay you can create relationships up-front and then query those
relationships, awesome. So (in my mind right now) I am imagining these
relationships would be made up by including a UserId entity in my Picture
Collection so that I can link back to my User Collection when I query
Picture. Is this correct? Or is this more of a SQL / relational database
way of thinking, and instead the 'verb' links functionality replaces this
approach?
- Collections such as User, Devices and Activities are pre-defined with
entities/properties, so that namespace is taken, but can you extend
entities/properties of these pre-defined collections as you please?
Many thanks for your time.
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris <https://twitter.com/SamJohnAllen>
www.zeta.net
01202 237137
@ZetaAgency <https://twitter.com/ZetaAgency>
On 15 July 2014 18:51, Rod Simpson <ro...@rodsimpson.com> wrote:
> Chris,
>
> Sounds like an awesome project! See answers inline below:
>
> --
> Rod Simpson
> @rockerston <https://twitter.com/rockerston>
> rodsimpson.com
>
> On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
>
> Hello there,
> I am creating an application that will require a detailed backend service.
> I am browsing to compare the advantages of using a system such as UserGrid
> over building something from scratch.
>
> I looked through your documents and became confused about
> Connections/Relations and Items, which brought me here. My application may
> potentially become large quite quickly, therefore I am looking for a system
> that is highly scalable.
> My database will require more information than your list of Collections
> provide, for example: The User table is going to need relations to other
> tables for things such as profile pictures, in-app messaging and locational
> information.
>
> My questions are:
> - Can you create a collection with any number of properties (within limits
> of disk space etc)?
>
> Collections hold entities, and entities can indeed hold any number of
> properties. For example, the Dogs collection can have any number of Dog
> entities, where each dog is a JSON object with properties, sub-objects, or
> sub-arrays. Basically anything that is supported in JSON can be put in an
> entity.
>
>
>
> - Can you create relations / joins between multiple collections and narrow
> the response time by making queries on top of this join / relation?
>
> Absolutely. This is also best practice. We don’t really call them
> “joins” as this implies a real-time Join like you would see in SQL. But
> you can indeed create relationships up front and then query those
> relationships.
>
>
> Your docs claim there is a way of creating new collections that link via
> certain 'verbs' such as 'following' or 'likes'.
> This is where I became confused, in order create a relation between 2 sets
> of information would I create collections for Profile Pictures, Locations,
> Messages etc and link them to User using a structure like (using the verb
> 'links-to'):
>
> GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
>
> Please let me know if this defeats the point of relational verbs
>
>
> Yes, you can absolutely do this. We are still in the process of porting a
> lot of documentation over to the Usergrid website. In the meantime, you
> can refer to the docs on the Apigee site:
>
> http://apigee.com/docs/app-services/content/connecting-users-other-data
>
> Everything under the "Apps: Build & Monitor” section should be relevant
> except the push notifications stuff.
>
> Rod
>
>
> Kindest Regards
>
> Chris Rogers
> Digital Developer
> chris@zeta.net
> @portchris <https://twitter.com/SamJohnAllen>
>
>
>
> www.zeta.net
> 01202 237137
> @ZetaAgency <https://twitter.com/ZetaAgency>
>
>
Re: Using UserGrid for our app
Posted by Rod Simpson <ro...@rodsimpson.com>.
Chris,
Sounds like an awesome project! See answers inline below:
--
Rod Simpson
@rockerston
rodsimpson.com
On July 15, 2014 at 10:40:54 AM, Chris Rogers (chris@zeta.net) wrote:
Hello there,
I am creating an application that will require a detailed backend service. I am browsing to compare the advantages of using a system such as UserGrid over building something from scratch.
I looked through your documents and became confused about Connections/Relations and Items, which brought me here. My application may potentially become large quite quickly, therefore I am looking for a system that is highly scalable.
My database will require more information than your list of Collections provide, for example: The User table is going to need relations to other tables for things such as profile pictures, in-app messaging and locational information.
My questions are:
- Can you create a collection with any number of properties (within limits of disk space etc)?
Collections hold entities, and entities can indeed hold any number of properties. For example, the Dogs collection can have any number of Dog entities, where each dog is a JSON object with properties, sub-objects, or sub-arrays. Basically anything that is supported in JSON can be put in an entity.
- Can you create relations / joins between multiple collections and narrow the response time by making queries on top of this join / relation?
Absolutely. This is also best practice. We don’t really call them “joins” as this implies a real-time Join like you would see in SQL. But you can indeed create relationships up front and then query those relationships.
Your docs claim there is a way of creating new collections that link via certain 'verbs' such as 'following' or 'likes'.
This is where I became confused, in order create a relation between 2 sets of information would I create collections for Profile Pictures, Locations, Messages etc and link them to User using a structure like (using the verb 'links-to'):
GET https://api.usergrid.com/my-org/my-app/users/fred/links-to/pictures
Please let me know if this defeats the point of relational verbs
Yes, you can absolutely do this. We are still in the process of porting a lot of documentation over to the Usergrid website. In the meantime, you can refer to the docs on the Apigee site:
http://apigee.com/docs/app-services/content/connecting-users-other-data
Everything under the "Apps: Build & Monitor” section should be relevant except the push notifications stuff.
Rod
Kindest Regards
Chris Rogers
Digital Developer
chris@zeta.net
@portchris
www.zeta.net
01202 237137
@ZetaAgency