In a scenario, the GET API call takes around 1 minute to fetch the updated data, updated by INSERT/UPDATE API calls.
So user updates some fields in the UI, and a UPDATE call has been made, the UPDATE call returns the updated fields value. However if the user refreshes the page with 1 minute of updating, the GET call will be made and which returns the OLD data.
How can I prevent the GET CALL within 1 minute of updating data?
Get data
Save data in localStorage, and note timeStamp i localStorage
Get data from localStorage if current time is less than 1 minute after timeStamp
Else get new data
Related
Let's consider I have 30 items in my db. And clientA will make an api call to get the first 10 records based on item updated time. And think of a use case where clientB updated the 11th record (item) by making some changes in it. But now when clientA makes an api call for next set of items based on the pagination page 2 (items from 11 to 20) It's because the clientB has updated the 11th item the pagination is going to break here (Bases on updated time 11th item will become 1 and 1 become 2, 2 become 3 ...10 becomes 11).There is a chance that clientA is will receive the duplicate data.
Is there any better approach for this kind of problem ??
Any help would be thankfull
I think you could retrieve all elements each time using no pagination at all, to prevent this kind of "false information" at your table.
If visualizing the actual values of each record is mandatory, you could always add a new function to your api working as a trigger. Each time a user modifies any record, this api's function will trigger a message for all active sessions to notify the user some data has been changed. As an example, think about something like the "twitter's live feed". In which when a new bunch of tweets are created, Twitter will notify all users to reload the page if they want to see realtime information.
quick question
i got a new related app plan to design so just need to know what is the best method to update the app with new data only rather then keep loading the API the idea of it is to only pull new data at the time the app was installed, any previous data will not be loaded in the app
Currently we planned to do this this way
1) First run use current time stamp and we store this timestamp
2) Second call we do is call the previous timestamp of (1) and store the current one (2)
3) third call we do we call previous timestamp of (2) and store current one which we call (3)
now if new data has been added between the calls of the timestamp then the API will reflect this the API will only show new data that has been added
so for example
1) First call
www.site.com/datetime=1234567890
This will return No Items
In between this time new data was added
2) Second Call (Take Previous Timestamp and store current timestamp)
Previous:www.site.com/datetime=1234567890
New: www.site.com/datetime=1234567891
this will return data in the API
3) 3rd Call
(Take Previous Timestamp and store currently timestamp)
Previous: www.site.com/datetime=1234567891
New: www.site.com/datetime=1234567899
Would something like this work or is there a better way of doing it?
We dont want to load API every single time thus each new timestamp query is only returning new items if applicable
Typically this is done with conditional headers, such as If-modified-since if you want to use a timestamp, or If-none-match if you wanted to use an ETag for versioning instead. You can see RFC 7232 for more information on conditional headers.
Typically your API would be broken up into multiple resources, so that you're only getting the chunks that have changed rather than having an all-or-nothing.
I'm really stuck at this. I have set up an endpoint that returns an array of data to my JSON RPC call made from the store. I'm expecting the grid to show only 30 records initially and then add more as I go on scrolling. I see that the pageSize only decides how much AJAX calls to make for the data. Meaning, if my data returned has 100 records, setting the pageSize to 20 makes 5 calls. But, all the 100 records are returned in every call. Besides, my infinite scroll doesn't work. Do I need to handle anything on the server side as well for making only the 30 records required and not all?
you need to interpret the start limit query parameters on the server side
so on initial call would be /?start=0&limit=20 so your server will return record 0-20.
if you begin to scroll the next request will be /?start=20&limit=40 and you will return record 20-40.
also notice the leadingBufferZone that is the record count that gets loaded into the non visibly area to allow smooth scrolling.
I'm looking for some assistance to sort out the logic for how I am going to deal with gaps in a feed timeline, pretty much like what you would see in various Twitter clients. I am not creating a Twitter client, however, so it won't be specific to that API. I'm using our own API, so I can possibly make some changes to the API as well to accomodate for this.
I'm saving each feed item in Core Data. For persistance, I'd like to keep the feed items around. Let's say I fetch 50 feed items from my server. The next time the user launches the app, I do a request for the latest feed items and I am returned with 50 feed items and do a fetch to display the feed items in a table view.
Enough time may have passed between the two server requests that a time gap exists between the two sets of feed items.
50 new feed items (request 2)
----- gap ------
50 older feed items (request 1)
* end of items in core data - just load more *
I keep track of whether a gap exists by comparing the oldest timestamp for the feed items in request 2 with the newest timestamp in set of feed items from request 1. If the oldest timestamp from request 2 is greater then the newest timestamp from request 1 I can assume that a gap exists and I should display a cell with a button to load 50 more. If the oldest timestamp from request 2 is less than or equal to the newest timestamp from request 1 the gap has been filled and there's no need to display the loader.
My first issue is the entire logic surrounding keeping track of whether or not to display the "Load more" cell. How would I know where to display this gap? Do I store it as the same NSManagedObject entity as my feed items with an extra bool + a timestamp that lies in between the two above and then change the UI accordingly? Would there be another, better solution here?
My second issue is related to multiple gaps:
50 new feed items
----- gap ------
174 older feed items
----- gap ------
53 older feed items
* end of items in core data - just load more *
I suppose it would help in this case to go with an NSManagedObject entity so I can just do regular fetches in my Core Data and if they show up amongst the objects, then display them as loading cells and remove them accordingly (if gaps no longer exist between any sets of gaps).
I'd ultimately want to wipe the objects after a certain time has passed as the user probably wouldn't go back in time that long and if they do I can always fetch them from my server if needed.
Any experiences and advice anybody has with this subject is be greatly appreciated!
I'm implementing a php page that display data in pagination format. My problem is that these data change in real time, so when user request next page, I submit last id and query is executed for retrieve more 10 rows from last id order by a column that value change in real time. For example I have 20 rows:
Id 1 col_real_time 5
Id 2 col_real_time 3
Id 3 col_real_time 11
Etc
I get data sorted by col_real_time in ascending order, so result is
id 2, id 1, id 3
Now in realtime id 2 change in col_real_time 29 before user send request for next page, user now send request for next results and because id 2 now is 29 he already see it.
How can I do?
Now in realtime id 2 change
You basically have to take a snapshot of the data if you don't want the data to appear to change to the user. This isn't something that you can do very efficiently in SQL, so I'd recommend downloading the entire result set into a PHP session variable that can be persisted across pages. That way, you can just get rows on demand. There are Javascript widgets that will effectively do the same thing, but will send the entire result set to the client which is a bad idea if you have a lot of data.
This is not as easy to do as pure SQL pagination, as you will have to take responsibility for cleaning the stored var out when it's no longer needed. Otherwise, you'll rather quickly run out of memory.
If you have just a few pages, you could:
Save it to session and page over it, instead of going back to the
database server.
Save it to a JSON object list and use Jquery to read it and page
over it.
Save it to a temp table indicating generation timestamp, user_id and
session_id, and page over it.