Backendless Support

iOS SDK Where Clause

Hi all,

I keep getting this error that I haven't seen before, and was wondering if you could shed some light (maybe I'm approaching this wrong).

3 tables are involved in this scenario:

Event --| (Optional 1:1) to Business_Location(via Location column)

Business --< (Optional 1:N) to Business_Location(via Locations column)

I want to retrieve all the events whose location's business (if specified) is "Active".

With the iOS SDK, I have this where clause specified on the query for the Event:

  1. p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #e44347}

    span.s1 {font-variant-ligatures: no-common-ligatures}

    (Location is null or (Location.Business[Locations].Active = true)) and ...

but I keep getting this:

  1. Invalid where clause at position 39: no viable alternative at input \'(Location.Business[\'

I have other queries in my app that use this pattern (the lookup on the parent), and they seem to work fine (They just don't have the scenario of the three levels / tables).

If I am indeed doing this wrong, how do I check a flag against a table's (event) child's (Location) parent (Business)?

Much appreciated,


Leave a Comment

Comments (4)


Hi Renato

Please provide your AppId

Regards, Vlad


Hi Vlad,

App ID is A324EB2B-1BF5-EB0A-FF36-62F47D198E00.



Hi Renato,

You got the right idea with the inverse relation, but unfortunately our whereClause parser is not smart enough yet to handle the inverse relation inside a relation. :)

But the good news is that you may accomplish the same with the following whereClause:

  1. Location IS NULL OR Location.objectId IN (Business[Active=true].Locations.objectId)

This is a new "subquery" syntax introduced in 4.2.0, so it's not documented yet. Effectively what is does is searches Business objects for which "Active = true" is true, retrieves their "Locations.objectId" properties and puts into the IN clause.


Hi Sergey,

I did notice that in your release notes, and was wondering if that could be of use here!

Thanks for the joining syntax for my use case - just checked it out, and it works great (also solved another similar use case I had)

Impeccable timing, by the way! ;)

Thank you!