Chris,

See answers inline below.

-- 
Rod Simpson
@rockerston
rodsimpson.com

On July 16, 2014 at 2:52:31 AM, Chris Rogers ([email protected]) 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
[email protected]
@portchris


​
​www.zeta.net
01202 237137 
@ZetaAgency


On 15 July 2014 18:51, Rod Simpson <[email protected]> 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 ([email protected]) 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
[email protected]
@portchris


​
​www.zeta.net
01202 237137 
@ZetaAgency


Attachment: ii_hv3lc7mj10_145efd805c737aec
Description: Binary data

Attachment: 161183BF-6B64-42D1-93C2-1023508EEF33
Description: Binary data

Reply via email to