Hi Petteri, That's definitely a bug; Usergrid should never return HTTP 500 internal server error unless Cassandra or ElasticSearch is inaccessible. Is there a stack trace that goes along with that error?
Dave On Tue, Jun 14, 2016 at 10:38 AM Petteri Sulonen < [email protected]> wrote: > Hi, everybody -- > > I'm evaluating Usergrid for our cloud services, and am starting to come > to grips with it. I have a question about error handling. > > I've noticed that the errors Usergrid returns seem somewhat > inconsistent. For example, when attempting to GET an entity that doesn't > exist directly from the collection (omitting org and app from path for > clarity): > > GET /things/ferrari > > will return an error "entity_not_found", but attempting to GET the same > entity through a connection where I "own" the entity: > > GET /users/me/owns/things/ferrari > > will return an "uncaught" error, with error_description "Internal Server > Error." > > Is this intentional? I was expecting to get an "entity_not_found" error > in both cases, as I think this would be a pretty common situation to > have in a system where entities are created and deleted dynamically. > > (If /things/ferrari actually exists and I own it, both queries return it > as expected, so that's cool.) > > If I've understood the design intent behind Usergrid correctly, these > connections are extremely important because I can map permissions to > them. Therefore it's not always possible to access objects directly > under the collection, as the user may only have permission to access > objects through a connection (e.g. "owns"). I like this scheme a lot, > it's simple, intuitive, yet powerful. > > If I've misunderstood something, I would greatly appreciate being set > straight. > > Thanks in advance, > > Petteri > > >
