Question #1: Is it possible to set up a Cron Job that only runs when changes are detected on a specific database?
I’ve never done any before, but from what I understand it’s a background process executing non-interactive jobs - I’m assuming the answer would be no, so in that case, is there an alternative I could use on InfinityFree to do the mentioned thing in the question?
Question #2: If a Cron Job runs daily performing changes to a database, would that affect any of the limits mentioned here?
Question #3: By default, Laravel uses MEMCACHED. Would it still work if I were to leave the default settings as they were and only chage the MEMCACHED_HOST variable in the .env file?
Here’s a simple example of how I plan to write the caching process, but not with files, as shown, but with just database data - as I’ve read somewhere on the forums that the InfinitFree servers already cache things like images, scripts, css, etc.
Question #4: Is this .htaccess file setup for Laravel valid?
Additional Information: I’m working on a demo for an E-Commerce website, which doesn’t actually do payment processing but it does perform CRUD operations and is open to the public to register / login with accounts that will be able to delete other users / products. There for, I’m looking for a way to make it so the database resets to the original state with it’s original data after someone has used it in an automatic way, since I don’t know when someone might actually use it.
Sorry about so many questions in a single thread, but I felt it might be a bit “spammy” to split them all in different topics.
No. Cron jobs are timed, what you are thinking of is not a cron job. The best way to do this is to using include to add in your script to whatever file is doing the update to the database.
No? It really depends on what your script is doing. But most likely it won’t do that.
There is not really a way to “detect” that the database changed. I would approach this the same way I explained in response to your first question.
Unfortunately, I’m not a Larvel user, so I cannot answer those questions. For htaccess, I would just try it and see what happens. At least you would know what the issue is.
One important thing to be aware of: our cron jobs tool is a web cron tool. This means it doesn’t run a system command, but instead calls a URL at the configured schedule. So you won’t be able to call php artisan schedule:run or other Artisan commands or other PHP code directly. But you could setup a web route that calls Artisan::call('schedule:run') instead.
There is no way to trigger code to be executed when data in a database changes. But in normal circumstances, all database interaction would be done through your code, which means you can setup your own triggers if certain things in the database are changed.
Be sure to look into Laravel’s Events system.
Yes, it will. Any web request (and especially any PHP execution) consumes server power, and this includes executions triggered with a cron job.
But it’s no worse than if you accessed the URL by hand, so don’t be too worried about it.
By default, Laravel uses disk cache. Redis or Memcached are also supported, but not enabled by default, and you need to have a separate Redis/Memcached server running to be able to use it. And we don’t have that.
Static files like images and CSS are just plain files stored on disk, and reading and serving those files is an extremely simple and fast operation. Our servers don’t cache these files because that would just make everything worse, and you should definitely not cache it with PHP because that’s much slower.
I’m not sure. It might be, but .htaccess rules aren’t easy to read.
But you could setup a web route that calls Artisan::call('schedule:run') instead.
Does that include something like Artisan::call('migrate:fresh') / Artisan::call('db:seed')?
…so don’t be too worried about it.
I kinda am, because if the answer to my question above is “Yes”, then the above commands, in my case, will call 12 .php migration files, 1 database seeder file and 12 factory files (maybe not these) - I don’t know if this is considered a lot, though, I will be doing testing once the website is done, which unfortunately will take a while, but I figured I’d inform myself early on.
By default, Laravel uses disk cache…
Thank you for this information. I must’ve misread something somewhere and thought it used MEMCACHED by default and since I’m not familiar with it, I thought that’s what I was using.
Static files like images and CSS are just plain files stored on disk, and reading and serving those files is an extremely simple and fast operation. Our servers don’t cache these files because that would just make everything worse, and you should definitely not cache it with PHP because that’s much slower.
Well, I understood the opposite from the admin post here. Perhaps they were talking about different type of caching.
Also, thank you for the .htaccess link. I found a video on YouTube that setup things in a smilar way. (Leaving the link here in case someone else finds it useful.)
Sure. But for populating the database, it may be easier to generate a sample database locally and then move that to your live site by exporting it from your local env and importing it through phpMyAdmin.
Yes, but I assume you’re not going to be recreating the database every minute of every day.
No hosting is unlimited. Please don’t let the fact that there are limits stop you from running any code at all.
And the number of PHP files being used it entirely irrelevant. What the code does makes all the difference.
Then I think you may have misunderstood. I think you’re referring to this statement:
There are no server side caches on our hosting, but by default we do enforce caching on static files like images, stylesheet and scripts because many websites tend to benefit from them.
Emphasis added for clarity. Files are not cached on the server, and you should not try doing that yourself. Browser level caching is enforced, but that’s different.