I would like my website to update at midnight (get the new data from the MariaDB database and refresh images, etc.) after that I want to cache (save) it throughout the day so that it doesn't have to use (PHP) and the database every time. Is that possible? It is important that the information can be freshly loaded at exactly midnight (or from zero when the first request is made) and is then constant for the entire website and every user until the next midnight. And in which file do you have to edit this in php.ini?
Related
I am wondering if there is a way to expire cached items after a certain time period, e.g., 24 hours.
I know that Apollo Client v3 provides methods such as cache.evict and cache.gc which are a good start and I am already using; however, I want a way to delete cache items after a given time period.
What I am doing at the minute is adding a TimeToLive field to every object in my Apollo schema, and when the backend returns an object, the field is populated with the current time + 24 hours (i.e. the time in 24 hours time). Then when I query the data in the front end, I check the to see if the TimeToLive field of the returned data is in the future (if not that means the data was definitely retrieved from the cache and in which case I call the refetch function, which forces the query to fetch the data from the server. However, this doesn't seem like the best way to do things, mainly because I have to iterate over every result in the returned data anch check if any of the returned objects are expired; and if so, everything is refetched.
Another solution I thought of was to use something like React Native Queue and have a background task that periodically checks the cache and deleted items that have expired. But again, I am not totally sold on this solution.
For a little bit of context here: I am building a cooking / recipes app - and recipes / posts are cached on the device; however, my concern is that a user could delete a post, but everyone else who has that post cached would still be able to see it, and hence by expiring the cached item at least they would only be able to see for a number of hours before it is removed. However they might be a better way to do this all together, i.e. have the sever contact clients with the cached item (though I couldn't think of any low lift solutions at the time of writing this)
apollo-invalidation-policies replaces the Apollo-client InMemoryCache with InvalidationPolicyCache and within the typePolicies you can specify a timeToLive field. If an object is accessed beyond their TTL, they are evicted and no data is returned.
i'm using laravel 5.7
i need to get the exchange rates and I want to create a scheduler and run every 5 minutes
Now, do you think it's possible to put the currency information in a config file or save it to a database and, of course, i think the cache could be, right?
In your situation the data will be changed only in 5 minutes. So when you get rates just store in the database and then get new values and cache them and give the user rates from cached information. But when the next 5 minutes left and you get newest rates then you must clear existing cache, store new values into database then get new values from database and store into cache and again give the rates to user from new cached content.
If your database getting grow day to day you must add additional logic to not store millions of records into cache every 5 minutes. I advice not to store dynamic content into the cache. Anyway if you want to cache you can use Redis, Memcached etc. But keep in mind to clear and again store new content into cache.
If you only get daily rates in every 5 minutes and not storing anything into database then you can use logic I have told above without database section. Directly save records into cache and clear when new rates getted.
And also add index to database table to get data more faster.
I must admit some of this caching stuff is over my head, so this may be a misunderstanding on my part of how this is supposed to function.
But essentially I have a View with the following traits:
pulling six different fields (2 text, 2 date, 1 boolean, 1 image - although that's just a text string too, right?)
four filters with two exposed to users
full pager showing 15 items per page (30+ items was making mysql go away)
sorted by date and sticky
time-based cache is turned on. Settings: query results-never,
rendered output-5 mins
Amount of data being pulled is huge: over 4,700 records
Only other caching solution on the site is stock Drupal page caching for anonymous and blocks, both enabled.
Cron is running every day although I suspect it fails sometimes.
The default filters are supposed to show all events from "time - now" until there are no more future event nodes.
Problem is, the cache sometimes shows "Now" as being yesterday or two days ago.
Shouldn't the cache refresh every five minutes? Am I misunderstanding how this setting works?
Shouldn't the View show up-to-date data even if cron doesn't run, or is cache expiration dependent on the cron running successfully? Or is the stock Drupal page cache overriding the Views cache for anonymous users?
Thanks!
I am working on a WP7 app that contains
CategoryGroups
Categories
Products
The rows for each of these entities are populated on first run of the application.
The issues is that when the app gets published, the rows in each of the entities will change (added, deleted, modified). I would like some suggestions on how I should handle this? Any pointers to existing code samples will be great?
I am using an object oriented database to store my entities. The app also allows the user to add their own entities (which get added to the database as personalized (flagged) entities). One solution I was thinking was to read an xml file from the server and then loop through the database entries and make the necessary modifications in the database. So, on the first run, all the entities will just get inserted. On subsequent runs, if the version number attribute in xml is different, then the system populated data is reloaded from xml but the user data is preserved.
Also, maybe only check for the new xml file on the server when internet connection is available and only periodically (like every 2 weeks).
Any other suggestions are welcome. If there is a simpler, cleaner way - please share.
Pratik
I think it's fair to say that this question has nothing to do with WP7 and everything to do with finding an efficient way to to compute and deliver update deltas.
Timestamp your items. When requesting an update, specify the time of last update. You server can trivially query for items newer than this and return a delta. At the client (ie in the phone) it is not necessary to store a last update time because you can simply add one second to the most recent timestamp in the items present on the phone.
What is the preferred method of refreshing a combo box when the data changes?
If a form is open and the combo box data is already loaded, how do you refresh the contents of the combo box without the form having to be closed and reloaded?
Do you have to do something on the Click event on the combo box? This would seem to be a potential slow down for the app if there is a hit to the database every time someone clicks on a combo box.
You must determine:
1) When does you data change?
If it depends on other users activity, so you can't determine whether it's changed without querying DB, you can figure out an optimal time for a refresh, like form loading or on every click, or you can use a timer control to refresh the data in a specific time.
2) When does your user need to know about that change?
Try to understand how urgent it is for the user to know about a change. Talk to them. Depending on that, decide when do you need to refresh your data.
Finally:
There isn't a correct way of doing that. It depends on a software structure, users' needs and on a specific situation.
Hope it helps. Good Luck!
UPDATE:
I can add a solutions, that I used recently. If something won't be clear, just ask.
I assume, your refreshing the combo from MS SQL Server.
If so,
1. Create a table , storing in it Combo's data changing date or a version.
2. onClick event or using timer control, which will check for changes every 5 minutes(or any other time), you can compare last change date (or version) of your combo with last change(or version) in that table we store last date(or version) and only if the date(or version) was changed, refresh the combo.
3. Last date (or version) you can store in a variable or in a textbox control, changing it's value every time you refresh the combo.
4. Update last date(or version) in that table if the data changes.
In this case, you'll just need to check for changes, not update them.
P.S. If this solution doesn't feet you, just refresh every time on click event. There's no better event for that case.
Depends on how many people will be using the form but in normal circumstances, using the onclick event of the select box is fine.
Using an ajax call is good because it means you dont have to load the entire page.
One thing is clear that you are using Dropdown means not more items you need to load in the dropdowm i think near about 20 or 30.
Then, what is the problem in database call ?
create Procedure that will use the execution plan and give you fast result.
or put a table which you need to load in cache and fill your cache at certain time
if data is change then load the data in dropdown.
I am working in Window application i am facing same thing but there is no better option
then call database or put it in the cache.
I can see two ways of doing this:
Put a "Refresh" button in UI and reload data only when the user clicks the button. It should be clear to the user (descriptive label, message box or whatever) that by hitting refresh its current selection(s) might change.
Monitor data changes in the database for the combo's underlying table. When data changes, the UI may either update immediately or just store a flag about data having changed (more on this later). In order to know rapidly when data changes, a database trigger seems the best solution to me: the trigger (UPDATE, INSERT, DELETE) is set on the combo's underlying table and increments a counter (datetime, version, whatever floats your boat) in a separate table created only for this purpose. Every time the combo is repopulated (including form load), the counter's value is attached (tag?) to it, to be compared with the current database value. Getting the current counter value could be done on a timer.
Now, if the two counters are different there are two options:
A. Update the UI immediately. I would normally hate such an UI but, not knowing what your actual requirements are, this may go as an option.
B. Set a flag that the UI should be updated. On the dropdown event, check the flag: if it's set, start by repopulating the combo.
In most situations I'd go without any refresh at all or with the first solution but it really depends on requirements.
HTH.
EDIT:
The purpose of the trigger/counter setup is not only to get change info fast but to actually know if data changed, which would be much more complicated to accomplish by directly querying the underlying table. Sorry if this wasn't clear in my initial post (or even after this addition) but English is not my native tongue.
Question 1: ComboboxName.Clear and then ComboboxName.Items.AddItem for each item.
Question 2: Of course this depends on how often the data changes and how big the list is, but I would probably put a timer that is set for every minute or so. This will prevent too many hits to the DB and will make sure your form isn't taking too much time filling in values to the combobox.