I am running into an issue where I am using iCloud and CoreData. When I update my core data database on one device, iCloud syncs the data to my second device correctly.
However, lets say I have the app running on both devices before I make the core data change. My second device has already made an NSFetchRequest (lets say its called fetchRequest1). After the import from iCloud was successful on my second device, calling the same request again from fetchRequest1 returns the all of my new data (anything that was inserted) but does not contain any updates to entities that had previously existed.
It seems like something is being cached oddly, since if I close the application and re-open it everything shows up correctly. In addition, if I make the fetch request and loop through each entity and call the NSManagedObjectContext refreshObject method on each one, then the data shows up! This however is obviously not always ideal, as a large database would not be able to handle this.
Does anyone know what may be causing this issue, or a way to flush the cache for fetch requests on a NSManagedObjectContext object?
Related
I'm experiencing an issue in my node application with accessing the contents of a mongoDB collection via mongoose.
this problem only ever happens the very first time my application makes a call to the database collection. what should occur when the user presses the submit button, is that the contents of the collection should be added dynamically to the DOM. However, this does not occur. but when I check the collection via the command line interface, the user submitted data is there, and then when I press the refresh button on the browser (which hits the same route the user was redirected to upon initially submitting the form) the data renders to the page like it should have the first time.
When I noticed this, i tried starting from scratch. I dropped my database, restarted my server, but this time, I used robo3t to create the db and the collection before I started my app and filled out the form data, and viola, when I submit my data and hit save, the information gets saved to the collection AND rendered the the page successfully the first time.
So i went and looked at the different Model methods provided by mongoose and thought maybe I just needed to add a function call to initialize the collection sometime before calling Model.find() but everything i'm looking at tells me that the collection is already (obviously) initialized when you call mongoose.model()
so i'm a little confused about what to do in order to make sure my data gets rendered to the webpage the first time the user submits information, rather than after refreshing.....i've been careful about awaiting all the async functionality but maybe I missed something?
the repo is here in the unlikely case someone wants to clone this and try to recreate the situation. Let me know if there is more information I can provide
https://github.com/Funkh0user/TripCheq-Travel-Assistant
Thank you.
I Solved it. I needed to rearrange some things such that the block of code responsible for doing some computations and then sending the result back to the application was in the callback for model.find()
Thanks!
I have a data table that is populated GUI -> API call -> node backend -> loop back -> mongo db. Just displaying data works fine using NGRX state management. I use a modal dialog to edit one of the fields, trigger a submit change action, call the relevant patch API and successfully update the relevant record(s).
In order to reflect this changed record in the GUI. I call the get API when the SUCCESSFUL_SUBMIT action comes. This works fine, but i think it's not the correct way to do things with NGRX and I worry that this will cause maintenance problems in the future.
So my question is, how do i reflect the changed state in the GUI. Please note that I do not wish to display the change in the GUI until i know that the DB patch was successful.
The image shows the table with the console log having just submitted a change to auto archive.
This seems fine to me, but:
if the POST object reflects the GET object and if the server doesn't modify properties, you could update your store without the extra GET
the POST response body could include the object to prevent the extra GET
Here is a common scenario: app is installed the first time and needs some initial data. You could bundle it in the app and have it load from a plist or something, or a CSV file. Or you could go get it from a remote store.
I want to get it from CloudKit. Yes, I know that CloudKit is not to be treated as a remote database but rather a hub. I am fine with that. Frankly I think this use case is one of the only holes in that strategy.
Imagine I have an object graph I need to get that has one class at the base and then 3 or 4 related classes. I want the new user to install the app and then get the latest version of this class. If I use CloudKit, I have to load each entity with a separate fetch and assemble the whole. It's ugly and not generic. Once I do that, I will go into change tracking mode. Listening for updates and syncing my local copy.
In some ways this is similar to the challenge that you have using Services on Android: suppose I have a service for the weather forecast. When I subscribe to it, I will not get the weather until tomorrow when it creates its next new forecast. To handle the deficiency of this, the Android Services SDK allows me to make 'sticky' services where I can get the last message that service produced upon subscribing.
I am thinking of doing something similar in a generic way: making it possible to hold a snapshot of some object graph, probably in JSON, with a version token, and then for initial loads, just being able to fetch those and turn them into CoreData object graphs locally.
Question is does this strategy make sense or should I hold my nose and write pyramid of doom code with nested queries? (Don't suggest using CoreData syncing as that has been deprecated.)
Your question is a bit old, so you probably already moved on from this, but I figured I'd suggest an option.
You could create a record type called Data in the Public database in your CloudKit container. Within Data, you could have a field named structure that is a String (or a CKAsset if you wanted to attach a JSON file).
Then on every app load, you query the public database and pull down the structure string that has your classes definitions and use it how you like. Since it's in the public database, all your users would have access to it. Good luck!
I am new to node and back end so please excuse me if my question seems dumb.
My use scenario is as follows:
I have a simple UI that will make only one ajax call at a given time. I have a node js backend that will take this call, make a login call to a webservice and use the response data to make another get call. When the call is over I will make a logout call and delete the login response data.
Problem:
The problem is that being single threaded and async and having no database the logout call will invalidated the login data for all the calls coming afterwards or that are in progress. I need a way to persist and encapsulate the data for each call without blocking the IO for each request.
Solution:
The only thing that I thought so far was to save the login data into dynamic created variables (based on the UI caller ID) and delete those vars when the call is over. However this seems like a very error prone solution that might also cause memory leaks.
I do not want to persist the data into a database and could not figure other solution, can you please advise?
I am using RestKit .22.0 with Core Data integration, both of which I'm pretty unfamiliar with. I followed the RKGist tutorial and was able to learn how to get objects from a REST endpoint, set up object mappings, add routes, and see the data from the web service correctly insert into the Core Data sqlite database.
Now I'm starting to work on persisting objects to the web service, but can't find any information on how best to do this. It seems like there are multiple ways to skin a cat with RestKit, so I wanted to see what the best practices are for POST/PUTing data.
When POSTing a new object, do you usually save the object in the managed object context first, then call [[RKObjectManager sharedManager] postObject:path:parameters:success:failure:]? Or is there some RestKit method that performs both of these operations at once?
If you first save the object in Core Data then POST it to the web service, is RestKit going to be able to update the already inserted object with the service's database identification attributes? Does the [[RKObjectManager sharedManager] postObject:path:parameters:success:failure:] method do this for you?
If there was an error POSTing the object, what is the typical way you'd retry the POST? Would you look for some sort of flag in the core data managed object and retry in a separate thread?
Thanks!
Yes, then the response from the POST updates that same object (perhaps filling in the server specified unique id)
Yes, updating the POSTed object is the default behaviour (you need to specify the response mapping and the response must be a single object)
No separate thread generally, and it depends what caused the error. Have a flag that indicates it's uploaded and retry when network connection is reestablished