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 [email protected] @portchris <https://twitter.com/SamJohnAllen> www.zeta.net 01202 237137 @ZetaAgency <https://twitter.com/ZetaAgency> On 7 August 2014 11:03, Chris Rogers <[email protected]> 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 > [email protected] > @portchris <https://twitter.com/SamJohnAllen> > > > > www.zeta.net > 01202 237137 > @ZetaAgency <https://twitter.com/ZetaAgency> > > > On 17 July 2014 08:59, Chris Rogers <[email protected]> wrote: > >> Thanks Rod, this makes sense. Thank you for all your help understanding >> User Grid. >> >> Kindest Regards >> >> Chris Rogers >> Digital Developer >> [email protected] >> @portchris <https://twitter.com/SamJohnAllen> >> >> >> >> www.zeta.net >> 01202 237137 >> @ZetaAgency <https://twitter.com/ZetaAgency> >> >> >> On 16 July 2014 22:13, Rod Simpson <[email protected]> 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 ([email protected]) 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 >>> [email protected] >>> @portchris <https://twitter.com/SamJohnAllen> >>> >>> >>> >>> www.zeta.net >>> 01202 237137 >>> @ZetaAgency <https://twitter.com/ZetaAgency> >>> >>> >>> On 16 July 2014 17:48, Rod Simpson <[email protected]> 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 ([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 <https://twitter.com/SamJohnAllen> >>>> >>>> >>>> >>>> www.zeta.net >>>> 01202 237137 >>>> @ZetaAgency <https://twitter.com/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 <https://twitter.com/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 <https://twitter.com/SamJohnAllen> >>>>> >>>>> >>>>> >>>>> www.zeta.net >>>>> 01202 237137 >>>>> @ZetaAgency <https://twitter.com/ZetaAgency> >>>>> >>>>> >>>> >>>> >>> >> >
B1209FEC-5E5B-4794-92E7-F317CEBF7681
Description: Binary data
FC966D97-3820-43A2-AF5B-AE174EAC6A4F
Description: Binary data
ii_hv3lc7mj10_145efd805c737aec
Description: Binary data
