Redirect Notice

As of April 12th, you must go to Progress SupportLink to create new support cases or to access existing cases. Please, bookmark the SupportLink URL and use the new portal to contact the support team.

You will be automatically redirected to SupportLink in 10 seconds.

How can we help you today?

Start a new topic
Discussions Kinvey Forums iOS
Answered

tmp_ prefix for entityId

What does the tmp_ prefix for entityId's created by DataStores that are in Cache mode signify?  Those created by .Sync and .Network don't have this prefix.  The tmp_ ones aren't going to change out from under me, are they?


Thanks,

-Chris

Screen Shot 2016-08-04 at 10.48.15 PM.png
Screen Shot ...
(59.1 KB)
Best Answer

Pasting Chris's reply here (as the reply created another ticket):


"Yeah, I've decided to use .Sync when saving, and .Cache with specific read policies when fetching, depending on the circumstance.  The  default .Cache behavior almost always doesn't fit my need, and I don't really want to manage a counter to determine when the calls are complete.  Its nice for refreshing table content because you can reloadData after each pass, but when doing fetches for other reasons, its not so useful. 


I also created another pattern called CacheElseNetwork that basically stops once it finds an object locally, preventing the second callback. This is for cases where the data in the cache doesn't need to be fresh, but it would be nice if it was there. 


Thanks,

-Chris"

3 CommentsSorted by Oldest First
Chris,

As the name suggests, it would be a temporary entity. I would like to understand your use case in a more detailed way and understand what issue you are facing?

Thanks,
Pranav
Kinvey Support

 

Chris,


I saw that you deleted your comment. Just wondering if you have figured out a solution?


Thanks,

Pranav

Kinvey Support

Answer

Pasting Chris's reply here (as the reply created another ticket):


"Yeah, I've decided to use .Sync when saving, and .Cache with specific read policies when fetching, depending on the circumstance.  The  default .Cache behavior almost always doesn't fit my need, and I don't really want to manage a counter to determine when the calls are complete.  Its nice for refreshing table content because you can reloadData after each pass, but when doing fetches for other reasons, its not so useful. 


I also created another pattern called CacheElseNetwork that basically stops once it finds an object locally, preventing the second callback. This is for cases where the data in the cache doesn't need to be fresh, but it would be nice if it was there. 


Thanks,

-Chris"

Login or Signup to post a comment
More topics in iOS
See all 437 topics