how can I extend the MySQLi class to explain all SQL queries on a given page?
Thanks.
There are several ways to do this. Here is one:
To start, you can get an explanation by simply prepending "EXPLAIN " to the mysql statement. See http://dev.mysql.com/doc/refman/5.0/en/explain.html for details on Mysql's explain.
Knowing that Mysql invocation, the mysqli::query and mysqli::prepare methods both take their first parameter as the $query string (side note: just use the Reflection class in a quick test script to get the current method or construct prototypes. You'll find extending mysqli_result class is not actually possible, but that shouldn't be a problem here).
Knowing that,
Store the mysql query string used in the calling of your extended methods as a new property of your extended `mysqli` class
Pass on the parent method's return results as normal
Create a new custom method to call this string property with `explain ` prepended and run a new separate query on that using any parent method or generic Mysqli invocation. This new method will be called any time you need to output the query explanation in your html view
Related
Sorry, the question was too bad to have a proper answer, so now I edited:
The manual says:
PDO::FETCH_CLASS: Returns instances of the specified class, mapping the columns of each row to named properties in the class.
My doubt is if the class extends form another class that have more atributes, will be this atributes instantiated?
Sorry if I'm not clear with the question, I'm not English speaker. Thank you all.
A good question.
For PDO, a class hierarchy doesn't actually matter. What PDO is doing is simply taking columns from database and assigning them to class properties, regardless of the class definition or inheritance.
If a property doesn't exist, PDO will try to create it.
If there is a property for which there is no column to map - then PDO will leave it alone.
As simple as that. So, it should create anything you select from the database.
As of the particular code you had in your question before - you have to debug it. Look, to see if anything was fetched, you are using whatever method printNickName(). But there could be any error either with this method or any intermediate process. Let me suggest you to create just empty classes, fetch your data in them, and check the properties directly.
After you make sure that all the properties are properly set, you may try with your custom class definitions. To debug the returned data I'd suggest to use
$stmt->execute();
var_dump($stmt->fetchAll(PDO::FETCH_CLASS, 'User'));
You may learn other details of PDO class handling from my article, Fetching objects with PDO
Hello all,
This query below contains the prepared statement that I would like to have mysqli processed
"SELECT password, salt FROM accounts WHERE username=?"
So far there seems to be no documentation on how fetch_array() works in OO-style with prepared statements. The closest thing I can find is http://php.net/manual/en/mysqli-result.fetch-array.php
Is there a particular "correct" way of doing it with mysqli prepared statements (the OO way)? thanks!
You won't get Objects directly out of the database with prepared statements.
Use fetch http://php.net/manual/en/mysqli-stmt.fetch.php to loop through the results, creating the required class instances and assigning them the data.
A model class will typically have a read method that does this. The method returns a instance, or an array of instances.
(Have a look at symfony models: http://www.symfony-project.org/book/1_0/08-inside-the-model-layer There are so-called peer models that provide static methods "to retrieve records from the tables. Their methods usually return an object or a collection of objects of the related object class".)
I've done mostly procedural programming for years and am trying to wrap my head around OOP and PDO. I've started converting an application I've written to using classes instead of standalone functions (it's a nightmare, but I think it will be worth it..) and would like to use PDO instead of the regular mysql_* functions. I'm kind of flying by the seat of my pants, just learning as I go along, and I'm not sure how I should handle the PDO object(s).
I know it would be stupid to create a new PDO object every time I need to make a query, so that leaves two ways that I can see:
Creating a PDO object in each class (i.e. every time an object is created, call a member function to create a PDO for it to use).
Create PDO object at the beginning of my application and pass it to the constructor of every object that is created, and all the objects share the PDO object.
What is the best way to do this?
Thanks for your advice!
Don't make more than one. You'll go crazy trying to manage all the DB connections.
One good solution would to make a singleton object for data access and retrieve it via it's static accessor method whenever you want to use the DB. That way you only ever have one place that manages DB access and PDOs. If you want to be a bit more MVC about it, you can put all SQL code in there too.
Depending on the size of the application, you probably want to use a Singleton to handle your database connection. Essentially, this will be a class that wraps your database connection and has a static function that will return your PDO object. However, because it's a Singleton it will only ever create one (assuming you don't make it more sophisticated). This saves you both from having to continuously make objects and from having to pass one object into all your objects, properly decoupling persistence from business logic.
Background:
We have a class which is used for accessing the mysql database. The methods within this class form a new mysql connection if a link isnt supplied as a parameter.
The way we've used the class in the system (not the database class) is to declare a database object and call the appropriate method and let the object scope end whenever it does.
We ran into a problem with code in the system (not the database class) that was creating a connection, inserting a record, closing the connection and then opening a new connection in order to fetch the max (id) to retrieve the last inserted id. (Obviously this wouldnt scale.)
Problem:
I'm trying to correct the code to replace the max (id) usage with mysql_insert_id in the appropriate functions and I need to revise the code structure in one of the following ways to PASS the database connection link.
I think I have the following choices:
1. Revise the class methods' code to use the class's internal link variable. Declare the database object once as a global object. Revise code usage all over the application to use this global variable.
2. Revise the class methods' code to use the class's internal link variable. Save the "MySQL link identifier returned by mysql_connect()" in a globally accessible variable and then use that when creating the database object. Minimal impact to use of the object and its methods.
Is there any other option? I'm edging for (2) because it has less of a code churn - but should I be doing so? Any potential issues?
Take a look at dependency injection and inversion of control containers.
Do this:
Remove all mysql_close() statements.
Convert all mysql_connect() to mysql_pconnect() to create persistent connections.
I have a PHP class that stores database query results, but also contains a PDO object so that the results can be updated/re-inserted/etc on the fly. A makeshift ORM, if you will.
Problem is, I need to serialize this class but instances of PDO cannot be serialized. I'm ok with that; by the time the object gets serialized, I have no need for the PDO instance.
Is there a way to mark a variable for exclusion from serialization within a class, like there are with some other languages? I understand I could manually unset() the PDO variable before I want to serialize the class, but with the current structure of the code, that would be a bit of a nightmare.
My saving grace here would be a __serialize() method that could be overridden, but it doesn't appear anything like that exists.
There's __sleep() and __wakeup().
Alternatively, you could implement Serializable.
Starting with PHP 7.4, there is also __serialize and __unserialize (see the Documentation) as a more usable alternative.
The Serializable interface might also be deprecated, and generally the magic methods are preferred (see also this).