CALL rebuild;
How would i call this each and every time dynamically without doing a query in database. I mean each time i update some value, i need to call this to make sure the changes are in effect.
Use a trigger.
http://dev.mysql.com/doc/refman/5.0/en/create-trigger.html
You could look at triggers? http://dev.mysql.com/doc/refman/5.0/en/triggers.html
Though they're generally avoided as they tend to make it harder to follow what you're app is doing.
You could also amend your data-access code to automatically append this command to any relevant update/insert that's happening?
Related
I want to introduce heartbeats to some of my scripts.
I have therefore added a service class that allows to save and update a timestamp in the DB.
It also keeps track of the last hearbeat and only queries the DB every 10s to prevent excessive DB calls.
Currently I need to manually add the heartbeat function call throughout my whole codebase.
Is there some way run it regularly automatically.
I found this that could be going into the right direction:
https://www.php.net/manual/en/function.uopz-set-hook.php
However this requires zend and to install an extension.
Is there some other way to do it?
A function like that should really only be used in DEV, never in prod, because it will be a massive impact on execution times.
I think you are searching for something like register_tick_function.
I'll not drop a code example here, because the PHP docs do contain good ones.
I've spent a few days making a script that essentially takes some data on a db2 system and creates new records for it in a mysql system. Along the way, it does some checks and I use looping to base inserts or updates on those conditions.
This script works, it returns what I expect and inserts/updates as expected. I've tested it for the deletion process, updates, inserts, whether records are expired or not......basically every function of this script I have tested thoroughly.
I feel like it's not as fast as it could be, it's probably more sequential and redundant than it should be as well.
I'm not used to working with PDO in a script like this, but I'm wondering what I could do here to fix performance/speed and redundancy. I know some of the logic may 'seem' redundant, but the logic is exactly where it needs to be, I'm just wondering if I could/should use functions to reduce calls or loops possibly.
Any help or advice is greatly appreciated.
this is tricky, I will get dragged over the hot coals for this, 1) you may want to not use PDO at all if you are sure that there is no risk of direct injection attack, 2) also I would look at implementing this sort of feature via PHP CLI i.e. via acron job on a curl trigger
In general PDO is a very expensive way to run a query. A simple string under mysqli_query() would be about 2.5x more efficient.
I think I'm probably looking at this the complete wrong way. I have a stored procedure that returns a (potentially large, but usually not) result set. That set gets put into a table on the web via PHP. I'm going to implement some AJAX for stuff like dynamic reordering and things. The stored procedure takes one to two seconds to run, so it would be nice if I could store that final table somewhere that I can access it faster once it's been run. More specifically, the SP is a search function; so I want the user to be able to do the search, but then run an ORDER BY on the returned data without having to redo the whole search to get that data again.
What comes to mind is if there is a way to get results from the stored procedure without it terminating, so I can use a temp table. I know I could use a permanent table, but then I'd run into trouble if two people were trying to use it at the same time.
A short and simple answer to the question: 'is a way to get results from the stored procedure without it terminating?': No, there isn't. How else would the SP return the resultset?
2 seconds does sound like an awfully long time, perhaps you could post the SP code, so we can look at ways to speed up the query's you use. It might also prove useful to give some more info on your tables (indeces, primary keys... ).
If all else fails, you might consider looking into JavaScript table sorters... but again: some code might help here
I am developing a Codeigniter (2.0.2) Application, which will utilise a Master database for all write operations (INSERT/UPDATE/DELETE) and a read replica for all read operations (SELECT).
Now I know I can access two different database objects within the code to route the individual requests to the specific database server, but i'm thinking there has a better way, automated way. I'll be using MySQL and Active Record, and also want to build in Memcache checking - although it won't be used immediately, I'd like the option there for the future, built in at this stage.
I'm thinking if its possible to add a hook/library of some kind to intercept the $this->db->query so that the following happens:
1) SQL Query received
2) Check if SELECT query
2a) If SELECT, see if Memcache is active, if so encode SQL and check Memcache for response.
2b) If no memcache response, or Memcache is not active, execute query as normal through READ MySQL server.
3) Query was NOT select, so execute query as normal through the WRITE MySQL server.
4) Return response.
I'm sure that looking at this, it should be quite simple to do, but no matter how I look at it i'm just not seeing a potential answer - but there's got to be one! Can anyone help/assist?
In addition, I also want the ability to be able to log all write SQL commands for troubleshooting, presumably the best way is to introduce 3a) Write SQL command to plain text file ... into the above scheme. I don't believe MySQL actually logs the non-SELECT queries in anyway ... does it?
That type of behavior is a little bit beyond the normal scope of CI. Unfortunately, your best bet is to manually extend the database drivers, specifically override the function simple_query or _execute (simple_query is a wrapper around _execute which simply ensures initialization). That is really the only place where you can guarantee that you can catch all of the queries and branch the logic accordingly. (You may also want to override close as that is the cleanup script)
(Personally, I would have a the SELECT DB load a secondary DB into itself and just call $write_db->simple_query conditionally, that seems like it would be the least trouble).
I have a mysql trigger that logs every time a specific table is updated.
Is there a way to also log WHICH PHP SCRIPT triggered it? (without modifying each php script of course, that would defeat my purpose)
Also, is there a way to log what was the SQL statement right before the UPDATE that triggered it?
Thanks
Nathan
Short answers: no and no. Sorry.
What are you trying to achieve? Perhaps there's another way....
no, but you can get some more specific direction.
first, if you're using persitent connections, turn them off. this will make your logs easier to use.
second, since it sounds like you have multiple code bases accessing the same database, create a different user for each code base with exactly the same rights and make each code base log in with a different user. now when you look at the log, you can see which application is doing what.
third, if you have the query log on, then the UPDATE immediately preceding the trigger will be the UPDATE that caused the trigger.
fourth, if your apps use any sort of encapsulation for the mysql connection, it should be trivial to modify it to write the call stack at the time a query is sent to the database to a file.
I've read through a few of the answers and the comments. I had one idea that would be usefuls only if your queries are passing through a single point. For example, if you have a database class that all queries are executed through.
If that is the case, you could possibly add a comment to the query itself. The comment would include the function call trace, and would be added to the query as an SQL comment.
Next, you would turn query logging on and be able to see where each query is getting called from in the log file.
If your queries do not pass through a single point, you may be out of luck.
One final suggestion would be to take a look at MySQL Proxy. I have not used it much but it is designed to do intermediate processing of queries. However, I still think you would need to modify your PHP scripts to pass additional information.