Can't seem to use LiveQuery with orQuery

[byroncoetsee]

Hi :)

I'm trying to subscribe to a query built from 3 subqueries... As follows:

let cancelledQuery = Sub_PFOrder.query()!.whereKey("cancelled", equalTo: true)
let collectedQuery = Sub_PFOrder.query()!.whereKey("collected", equalTo: true)
let expiredQuery = Sub_PFOrder.query()!.whereKey("expired", equalTo: true)

let specificOrdersQuery = PFQuery.orQuery(withSubqueries: [cancelledQuery, collectedQuery, expiredQuery])
specificOrdersQuery.fromLocalDatastore()

and then:

subscription = Client.shared.subscribe(specificOrdersQuery).handle(Event.updated) { _, message in
        print(message)
}

Problem is, when I run the code I get an error: Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Invalid type in JSON write (PFQuery)'

Notes:

• ParseLiveQuery is working if I sub to a normal PFQuery.
• Using the latest cocoapods release
• Swift 4

[flovilmart]

Do you have the server logs? It usually indicates that the response is not properly formatted JSON string

[byroncoetsee]

Thanks for getting back to me :)

They seem to only print info: Create new client: 0 each time the app starts... But that's all. I've enabled VERBOSE too...

I have a feeling it's an issue with the outgoing part

[byroncoetsee]

Managed to get verbose working...
Here is the only bit of logs the server throws out before the app crashes:

info: Client disconnect: 0
verbose: Current clients 0
verbose: Current subscriptions 0
verbose: REQUEST for [POST] /parse/classes/_Installation: {
  "timeZone": "Africa/Johannesburg",
  "appVersion": "1",
  "appName": "-------",
  "deviceType": "ios",
  "badge": 0,
  "installationId": "8647541c-5cdf-4f3a-b218-703ce05f8309",
  "appIdentifier": "---------",
  "parseVersion": "1.15.4",
  "localeIdentifier": "en-US"
} method=POST, url=/parse/classes/_Installation, host=192.168.1.138:1337, x-parse-client-version=i1.15.4, accept=*/*, x-parse-application-id=------, x-parse-installation-id=8647541c-5cdf-4f3a-b218-703ce05f8309, accept-encoding=gzip, deflate, x-parse-os-version=11.2 (17B1003), accept-language=en-us, content-type=application/json; charset=utf-8, content-length=268, user-agent=----%----/1 CFNetwork/893.14 Darwin/17.2.0, connection=keep-alive, x-parse-app-build-version=1, x-parse-app-display-version=1.0, timeZone=Africa/Johannesburg, appVersion=1, appName=-----, deviceType=ios, badge=0, installationId=8647541c-5cdf-4f3a-b218-703ce05f8309, appIdentifier=------, parseVersion=1.15.4, localeIdentifier=en-US
verbose: Request: {"sessionToken":"","op":"connect","applicationId":"------"}
info: Create new client: 1
verbose: Push Response : "{\"op\":\"connected\",\"clientId\":1}"
verbose: RESPONSE from [POST] /parse/classes/_Installation: {
  "response": {
    "updatedAt": "2018-02-07T00:07:15.633Z"
  }
} updatedAt=2018-02-07T00:07:15.633Z

Apologies for all the ------...

[byroncoetsee]

I've managed to track down (I think) where the problem lies... It seems that when serialising the query built from orQuery, it fails when it reaches and tries to (in this case) turn the 3 PFQuery objects in JSON...

[byroncoetsee]

(Sorry for all the comments one after the other, just letting you know as I go)

Looks like the problem does indeed lie in the unwrapping of those 3 queries when serialising the data... A "1st tier" query is unwrapped all nicely (see the updatedAt constraint? That's a standard where clause attached the the 1st tier query)... Then we get to the or constraint. Here, none of the following queries are unwrapped, leaving them as their original objects. It should unwrap them in a similar fashion to the 1st tier query... I believe that would solve the problem.

EDIT: Line 29 of the file Operation.swift needs to unwrap queries below the query key.

EDIT: I think maybe the file QueryEncoder.swift would be the one to handle the unwrapping actually.

EDIT: QueryEncoder.swift is definitely the place where this will be handled. I don't know in what format the or part needs to be for the liveQuery server to understand it though so I can't attempt to solve it.

[mseijas]

@byroncoetsee Were you ever able to solve this issue? I'm running into the same problem

[lordjjl]

@byroncoetsee I'm seeing this issue as well.

[danielchangsoojones]

I am still having this issue also

[flovilmart]

If you're willing to provide a fix we'll gladly review it!