Parse query from LocalDataStore for object with PFRelation returns empty

[MatthieuTnsc]

I am trying to implement Local datastore in my application but I have an issue when I need to query relation from local Datastore.

Here is my query :

var relation:PFRelation = PFUser.currentUser()!.relationForKey("Friendship")
var query:PFQuery = relation.query()!

This query returns what I'm looking for when fetched by network but then I Pin all the results and re-query from localDatastore, and the result is empty.

I am using the newest Parse iOS SDK (1.8.1)

This issue is linked with these topics :

• (apparently "on hold") https://developers.facebook.com/bugs/444556112335977/
• (said it was fixed in 1.7.3) https://developers.facebook.com/bugs/938451159512610/

[nlutsenko]

Can you share a full code snippet that fails for you. An ideal scenario would be a failing unit test or a full repro project on github.

[MatthieuTnsc]

Here is a code snippet with parts of the code I use : https://gitlab.com/snippets/7703
I don't have time nowadays to create a full repro project on github but if my snippet isn't enough I'll try to.

[dtaitz]

Has this been resolved? I am also having this same issues (PFRelation queries in the localdatatsore).

[Rollaway]

I'm getting this with 1.8.5. Let me know if there's anything I can do to help squash.

[nlutsenko]

Hey guys, the most helpful thing here would be to get a repro project from anyone of you that has this issue reproduced. Or a failing unit test?

[dtaitz]

Hi @nlutsenko, I took some time to further investigate this issue and realized that the issue was not in querying the localDatastore but actually pinning large amounts of objects to the localDatastore using the method +(BFTask *)pinAllInBackground:(NSArray *)objects.

I realized this because when I pinned (using pinAllInBackground:) and then did a localDataStore query for a PFRelation of only 6-10 objects, I was able to get my desired results. On the other hand, when I did the same two methods with a PFRelation of ~600 and ~1000 objects, I failed to get the objects when I did the localDatastore query (yet the BFTask returned a result of 1 which made me think the pinning work).

To test this assumption, I decided to iterate through the PFRelation of ~1000 objects, and then individually pin each object using - (BFTask *)pinInBackground. After doing this, I did the same local query on the PFRelation and was able to retrieve my desired objects.

Hope this helps. Happy to clarify.

[nlutsenko]

Great, this definetly helps. Any chance you can setup a project that shows the issue?

[dtaitz]

Yeah, I will build something now. Shouldn't take too long.

[dtaitz]

@nlutsenko I just shared you with a fairly simple that replicates this issue. It logs the results of the query to server, the pin task, and the local query to show what is going wrong.

[nlutsenko]

@dtaitz, many thanks for the repro project, I can see the issue now.
It looks like to be related to the fact that you have the same User inside the relation, which resets the value of the relation back to the original state.

I'll look into the ways to fix it overall - but in the meantime, removing the currentUser from inside the relation fixes the problem in your case.

[dtaitz]

Thank you! That makes sense. I appreciate you pointing that out  

I appreciate you taking the time to help!

On Sat, Oct 10, 2015 at 8:49 PM, Nikita Lutsenko [email protected]
wrote:

@dtaitz, many thanks for the repro project, I can see the issue now.
It looks like to be related to the fact that you have the same User inside the relation, which resets the value of the relation back to the original state.

I'll look into the ways to fix it overall - but in the meantime, removing the currentUser from inside the relation fixes the problem in your case.

Reply to this email directly or view it on GitHub:
#72 (comment)

[dtaitz]

@nlutsenko removing the Current User from the PFRelation solves the issue on the sample project I gave you but not on my actual project.

I keep coming across this lock with [User currentUser] when trying to find workarounds for my current problem with querying the localdatastore with PFRelations.

https://gist.github.com/dtaitz/add05892cec971f40766

I update my [User currentUser] a decent amount at launch of the app but have not seen this issue until recently.

Please let me know what I can do to help

[dtaitz]

@nlutsenko I am still experiencing this issue. Is there anything I can do to help figure it out?

[nlutsenko]

@dtaitz, the thing is - I think I know where the problem is coming from, but unfortunately I don't have a solution for our codebase that solves this just yet.

Our decoding logic resets the relations for any object whenever there is an update of data coming from the server for that object. If it happens after the fact that we were able to cache the objects that we know about on the client, but before we were able to persist it to the LDS - you get the known objects on a query reset to the previous state, which means that relations doesn't properly report known objects.

One of the suggestions at the current time for you to fix it, that I have is to:

• After querying relational objects from LDS for a given user - pin them to LDS with a specific pin name (say '(User.objectId).friends')
• This will give you an ability to locally query from a specific pin without relying on the relational query locally.

Another way would require more work, but probably is better long-term: do not use relations directly, but rather create your own table that connects 2 users together. This approach would give you an ability to perform the same query, but instead of relying on the relation field - get the query for a different object class and work based on that. Roughly - recreate relations from scratch by yourself :) This approach is also slightly more flexible, since you can query the objects the other way around aka bi-directional queries from both the owner of the friendship as well as the user who is a friend, so you can display to both of them the fact that the friendship exists.
Say a schema for those objects would look something like:

• FriendshipConnection:
  • friend1 -> Pointer("_User")
  • friend2 -> Pointer("_User")

Let me know if any piece of this above doesn't make sense or is not clear. (tried my best, but it's somewhat hard to explain).

[dtaitz]

@nlutsenko thanks for getting back to me.

I will look into both approaches now. The second one is definitely more extensive! Do you think there will be any performance issues with the second approach at scale? I can imagine quite a few objects needing to be created and stored in the LDS in that case.

Thanks again!

[nlutsenko]

Performance:
First approach:
Going to be faster, since you have a smaller pin.
Second approach:
If you optimize it further for lazy-loading, where if you don't need to get the details for your friends - you can not expand the pointer (not specify includKey: on the query), and then fetch the users data when you need it in batches. This is going to be cheaper than fetching all users from your relation.

The second approach is also going to give you slightly better security, since you can specify ACL on the FriendshipConnection object only to 2 users, which will restrict reading of that information only to those users.

[dtaitz]

@nlutsenko that makes sense. I will let you know how it goes.

As always, appreciate you taking the time to explain this.

[nlutsenko]

No problem, always happy to help. :D

[nickynick]

Any news on this? I'm currently experiencing this issue in a setup with two classes, let's say Category and Item. A category has a relation of many items; an item doesn't have a column pointing back to the category.

The steps I'm doing:

• query the category's items from the server via PFRelation, everything's fine;
• pin the fetched items with a named label;
• on the next app launch, query the same category's items, but now with [query fromLocalDatastore];; getting zero items in result.

Unfortunately, I can't apply any of these two workarounds above due to time and architectural limitations... Any help would be greatly appreciated :)

[nickynick]

@nlutsenko Sorry for bumping - I'm just wondering if you've seen the last message :) A "no" would be a good answer too, I just need to do something about this in our app asap. In case nothing changed with this issue, I guess I'll have to use the first workaround idea, somehow.

[livingstonef]

I guess we just cannot create relationships on objects until they are saved in the cloud.

I am trying to create a parse one-to-many relation in a network independent way. I guess my issue is similar to this http://stackoverflow.com/questions/15327255/how-to-make-sure-saving-parseobject-and-parserelation-using-saveeventually.

It is currently impossible to add PFRelations to PFObjects saved with saveEventually (local datastore is enabled). Trying to fetch a relation on an object that was saved offline in this manner fails with the "nilError" so struggling to understand what is wrong or how to circumvent this... if this is intended..

//Swift..

class Project : PFObject, PFSubclassing {}
class Student: PFObject, PFSubclassing {}

//..

let studentA = Student()
let studentB = Student()

//Saving eventually

studentA.saveEventually()
studentB.saveEventually()

//Research project with participants..

let research:Project = Project()
let participants= research.relation(forKey: "participants")

//I have tried multiple options here 
//..including adding the participants outside or inside saveEventually callbacks.

participants.add( studentA )
participants.add( studentB )

//
research.saveEventually({
    (success, error) in
        if success {
            research.pinInBackground()
        }
})

//...some time later whilst app still offline ...

let query:PFQuery<PFObject>? = participants.query()
do{
     let aParticipant = try query?.getFirstObject() //
}catch {
   Swift.print("Error on fetching object in participant relationship : ", error)
}

//This always fails with... 
//"Error on fetching object in participant relationship : nilError"

[TomWFox]

@nickynick @livingstonef Are you still experiencing this issue?