Doctrine - how to get the SQL INSERT query, in the postSave() event? - php

I would like to get the exact SQL INSERT query that Doctrine generates when an object's save() method is called.
Preferably, I would like to get it in the postSave() event of the model and log it in a txt file.
For instance:
<?php
$user = new User(); // A Doctrine Model with timestampable behavior enabled
$user->first_name = 'Manny';
$user->last_name = 'Calavera';
$user->save();
?>
I want to get/log the following SQL query:
INSERT INTO user (first_name, last_name, created_at, updated_at) VALUES ('Manny', 'Calavera', '2010-08-03 12:00:00', '2010-08-03 12:00:00');
The background for needing this, is that I wish to mass-import later the data by parsing the txt file.

I don't think there is any easy way to do this since the behaviour of save() varies depending on a few different things (if you're inserting/updating).
If you had created a doctrine query object, then you can call the getSqlQuery() method like this:
$q = Doctrine_Query::create()
->select('u.id')
->from('User u');
echo $q->getSqlQuery();
but the save() is a method, not an object so this won't work. I think you'll have to hack in some code to detect whether you're inserting or updating and build a query to log on the fly and then use save().
I know this suggestion is not ideal because it is not logging 'exactly' what save() is doing but for the purposes you stated it should still work just as well.

Why don't you try to see how the symfony developers do it? Check their WebDebug Toolbar for Doctrine here. The WebDebug Toolbar outputs all query that you do on a page.
There's a hook on DoctrineEvent, and I think you can modify the code to do what you want. Check the getDoctrineEvents and getSqlLogs method.
Hope this helps. If you need further explanation, please write it in comment, I'll try my best to explain.

Take a look here: http://www.phpandstuff.com/articles/codeigniter-doctrine-scratch-day-8-hooks-profiling-dql and go to the section headed Profiling with Doctrine and Creating a Profiler Hook. Altough this is for the use with the CodeIgniter framework, it can be easy adopted to your own environment since the code has no dependencies to the framework.
You basically want to set up a Connection Profiler and let it write all queries to a file. I suggest appending all queries to the file to have a better "log"-like feeling. Don't get confused by many framework talk inside the articles. The examples work very well (with a little understanding and copy&pasting) in other scenarios.

you can use the profiler from the sfDoctrineDatabase class. Use the getQueryExecutionEvents to grab all queries.
$databaseManager = sfContext::getInstance()->getDatabaseManager();
if ($databaseManager) {
foreach ($databaseManager->getNames() as $name) {
$database = $databaseManager->getDatabase($name);
if ($database instanceof sfDoctrineDatabase && $profiler = $database->getProfiler()) {
foreach ($profiler->getQueryExecutionEvents() as $event) {
$conn = $event->getInvoker() instanceof Doctrine_Connection ? $event->getInvoker() : $event->getInvoker()->getConnection();
$params = sfDoctrineConnectionProfiler::fixParams($event->getParams());
$query = $event->getQuery() ;
foreach ($params as $param) {
$param = htmlspecialchars($param, ENT_QUOTES, sfConfig::get('sf_charset'));
$query = join(var_export(is_scalar($param) ? $param : (string) $param, true), explode('?', $query, 2));
}
// log the $query here, or use the symfony's logger
// sfContext::getInstance()->getLogger()->debug(sprintf('Query Run !! %s ', $query));
}
}
}
}
dont forget to join the query with the parameters (so it will replace ? with the values )
:D

You can convert you DQL query to SQL by this function: http://tokarchuk.ru/2010/12/dql-query-to-raw-sql/

Related

Escape SQL queries in PHP PostgreSQL

I have a website with lots of PHP files (really a lot...), which use the pg_query and pg_exec functions which do not
escape the apostrophe in Postgre SQL queries.
However, for security reasons and the ability to store names with
apostrophe in my database I want to add an escaping mechanism for my database input. A possible solution is to go
through every PHP file and change the pg_query and pg_exec to use pg_query_params but it is both time consuming
and error prone. A good idea would be to somehow override the pg_query and pg_exec to wrapper functions that would
do the escaping without having to change any PHP file but in this case I guess I will have to change PHP function
definitions and recompile it which is not very ideal.
So, the question is open and any ideas that would
allow to do what I want with minimum time consumption are very welcome.
You post no code but I guess you have this:
$name = "O'Brian";
$result = pg_query($conn, "SELECT id FROM customer WHERE name='{$name}'");
... and you'd need to have this:
$name = "O'Brian";
$result = pg_query_params($conn, 'SELECT id FROM customer WHERE name=$1', array($name));
... but you think the task will consume an unreasonable amount of time.
While it's certainly complex, what alternatives do you have? You cannot override pg_query() but it'd be extremely simple to search and replace it for my_pg_query(). And now what? Your custom function will just see strings:
SELECT id FROM customer WHERE name='O'Brian'
SELECT id FROM customer WHERE name='foo' OR '1'='1'
Even if you manage to implement a bug-free SQL parser:
It won't work reliably with invalid SQL.
It won't be able to determine whether the query is the product of intentional SQL injection.
Just take it easy and fix queries one by one. It'll take time but possibly not as much as you think. Your app will be increasingly better as you progress.
This is a perfect example of when a database layer and associated API will save you loads of time. A good solution would be to make a DB class as a singleton, which you can instantiate from anywhere in your app. A simple set of wrapper functions will allow you to make all queries to the DB go through one point, so you can then alter the way they work very easily. You can also change from one DB to another, or from one DB vendor to another without touching the rest of the app.
The problem you are having with escaping is properly solved by using the PDO interface, instead of functions like pg_query(), which makes escaping unnecessary. Seeing as you'll have to alter everywhere in your app that uses the DB, you may as well refactor to use this pattern at the same time as it'll be the same amount of work.
class db_wrapper {
// Singleton stuff
private $instance;
private function __construct() {
// Connect to DB and store connection somewhere
}
public static function get_db() {
if (isset($instance)) {
return $instance;
}
return $instance = new db_wrapper();
}
// Public API
public function query($sql, array $vars) {
// Use PDO to connect to database and execute query
}
}
// Other parts of your app look like this:
function do_something() {
$db = db_wrapper::get_db();
$sql = "SELECT * FROM table1 WHERE column = :name";
$params = array('name' => 'valuename');
$result = $db->query($sql, $params);
// Use $result for something.
}

what is the way to use PDO in slim framework?

I start a new slim project with twig support, I want to use PDO as database layer, what is the way to integrate? or just use GLOBAL $db?
Thanks.
i'm against mutable globals. you could use a simple factory method returning your connection:
function db() {
static $db = null;
if (null === $db)
$db = new PDO(...);
return $db;
}
if you're about to deal with more of such problems, consider a registry (see this one).
Regarding mutable globals:
I'm against such things because, well, they are easy to be mutated.
What happens if, during the flow of a program, circumstances change unexpectedly?
Things break.
If you're the only one working on the project, globals might be ok.
But from my experience, even in this scenario, keeping track of global variables becomes a hassle and offends logical organisation of your code.
What if you come to the point of sharing your code with other who will overwrite such global?
Also, globals contradict the methodology of data encapsulation in the context of seperation of concerns.
All this plays into the big, wide science of software architecture.
Additionally, using a factory in this specific case ensures that you only keep one single reference to the connection to your database.
Look this project: Slim-PDO (github)
Documentation is here
Install via composer: $ composer require slim/pdo
Simple usage:
$app->container->singleton('database', function () use ($app) {
return new \Slim\PDO\Database($app->config('db.dsn'), $app->config('db.usr'), $app->config('db.pwd'));
});
// SELECT * FROM users WHERE id = ?
$selectStatement = $app->database->select()
->from('users')
->where('id', '=', 1234);
$stmt = $selectStatement->execute();
$data = $stmt->fetch();
// INSERT INTO users ( id , usr , pwd ) VALUES ( ? , ? , ? )
$insertStatement = $app->database->insert(array('id', 'usr', 'pwd'))
->into('users')
->values(array(1234, 'your_username', 'your_password'));
$insertId = $insertStatement->execute(false);

Yii sql query bindings, with params, do not work properly

I'm new to Yii and everything seems good, but the problem is, when I`m using the binding params, like (DAO stile):
$command = $this->conn->createCommand($sql);
$command->bindColumn("title", "test_title");
$result = $command->query();
or (Active Record):
$row = Movies::model()->find("m_id=:m_id", array(":m_id"=>27));
or
$row = Movies::model()->findByPk(24);
I've tried everything:
1) added a config param to mysql config. in main.php - 'enableParamLogging' => true
2) changed strings from ' to "
3) added another param just in case of mysql versions - 'emulatePrepare'=>true
Nothing works for me.
I thought that the problem is in params, but bindColumn method doesn't use it, so my presumption is that some module of Yii hasn't been include in config file or something like that.
My model looks like this (created in /models dir):
class Movies extends CActiveRecord {
public static function model($className = __CLASS__) {
parent::model($className);
}
}
Just for everybody to avoid unnecessary questions: the database is configured properly in main.php conf file, there is a table movies, there is a PKs 24 and 27 also.
All native SQL works fine, except using in DAO special methods to bind some params and if in AR using findByPk or find. I hope that this is clear, guys don't bother me with obvious simple technical possibilities, that I can (as U presume) did wrong.
PS Another helpful info - when calling
$command->bindColumn("title", "test_title");
FW's throwing an Exception - CDbCommand and its behaviors do not have a method or closure named "bindColumn". So, as mentioned above, I think that Yii don't see those special methods and this is certain. How can I repair it?
Ok, why this code don't work either? There is no Exceptions, just blank page.
$sql = "SELECT title, year_made FROM movies WHERE year_made=':ym'";
$command = $this->conn->createCommand($sql);
$command->bindParam(":ym", "2012", PDO::PARAM_STR);
$result = $command->query();
The DAO binding isn't working because there is no bindColumn. You only have bindParam, that binds a variable to a column, or bindValue, that binds a value.
I don't know what's wrong with the AR query though.
Edit: Your DAO code should look like this:
$sql = "SELECT * FROM sometable WHERE title = :title";
$command = $this->conn->createCommand($sql);
$command->bindParam(":title", $tile_var);
$result = $command->query();
Have you generated movie model by Gii generator or you wrote it by yourself?
Edit:
As I know you have to add tableName
public function tableName() {
return 'movies';
}
You may have two separate issues. At least your DAO code (if that is what you actually have in your code) is binding wrong.
Binding needs to occur before the query is done (and it's done on the command object), not on the result object. See more info here: http://www.yiiframework.com/doc/guide/1.1/en/database.dao#binding-parameters
As far as your AR queries go, those could also be problematic. You can use findByAttributes instead of this line (although your line should work):
$row = Movies::model()->find("m_id=:m_id", array(":m_id"=>27));
The below should work if you have a standard id key. If you don't (and are using m_id, have you set your model's primaryKey() function up?
$row = Movies::model()->findByPk(24);
Also, you'll be getting a model object back, not a row if that changes how you are handling the results ...

Is it better to cache to cache the object in the controller or the query in the method?

At the moment I'm using php and apc in my mvc based site, it's a custom built simple mvc so I'm trying to build it to fit my needs.
However I'm unsure where is the preferred location in which to handle caching?
I have two choices (I think) .. either do all caching in the various controllers which would mean objects were stored in the cache, or store returned data from queries in the cache inside the method:
Controller Example:
function showPage() {
$pageOb = new Page();
$key = md5('pageOb->getQuery()');
if(!$data = apc_fetch($key)){
$data = $pageOb->getQuery();
apc_add($key, $data, 600);
}
require 'template.php';
}
Method Example:
function getQuery(){
$sql = "SELECT * FROM table";
$key = md5('query'.$sql);
if(!$data = apc_fetch($key)){
$core = Connect::getInstance();
$stmt = $core->dbh->prepare($sql);
$stmt->execute();
$data = $stmt->fetchAll();
apc_add($key, $data, 600);
}
return $data;
}
It kinda depends on how you understand and implement the Model layer. This would be how I would write the cache-related code in the Service level objects:
$user = $this->domainObjectFactory->build('User');
$user->setId(42);
if ( !$this->cacheMapper->fetch('User', $user) )
{
$mapper = $this->mapperFactory->build('User');
$mapper->fetch($user);
}
If you do not understand the terms this comment (skip to "side notes") might help. It would take too long to repeat the whole thing again.
As I understand it, the cache itself is just a different form of storage. And thus it is just another part of Data Source Layer(where mappers, DAOs and similar structures come from).
You shouldn't have data-model concerns bubbling up into your Controller. This principle is encapsulated in SRP: http://en.wikipedia.org/wiki/Single_responsibility_principle
Your second solution is better, but it would be improved by further abstracting the retrieval of data from the source of data. Here is a good reference article on the subject, although the language being used is different the patterns still hold: http://www.alachisoft.com/resources/articles/domain-objects-caching-pattern.html

Code coverage with phpunit; can't get to one place

In the xdebug code coverage, it shows the line "return false;" (below "!$r") as not covered by my tests. But, the $sql is basically hard-coded. How do I get coverage on that? Do I overwrite "$table" somehow? Or kill the database server for this part of the test?
I guess this is probably telling me I'm not writing my model very well, right? Because I can't test it well. How can I write this better?
Since this one line is not covered, the whole method is not covered and the reports are off.
I'm fairly new to phpunit. Thanks.
public function retrieve_all()
{
$table = $this->tablename();
$sql = "SELECT t.* FROM `{$table}` as t";
$r = dbq ( $sql, 'read' );
if(!$r)
{
return false;
}
$ret = array ();
while ( $rs = mysql_fetch_array ( $r, MYSQL_ASSOC ) )
{
$ret[] = $rs;
}
return $ret;
}
In theory, you should be better separating the model and all the database related code.
In exemple, in Zend Framework, the quickstart guide advise you to have :
your model classes
your data mappers, whose role is to "translate" the model into the database model.
your DAOs (or table data gateway) that do the direct access to the tables
This is a really interesting model, you should have a look at it, it enables you to really separate the model from the data, and thus to perform tests only onto the model part (and don't care about any database problem/question)
But in your code, I suggest you to perform a test where you have the dbq() function to return false (maybe having the db connexion to be impossible "on purpose"), in order to have full code coverage.
I often have these kind of situations, where testing all the "error cases" takes you too much time, so I give up having 100% code coverage.
I guess the function dbq() performs a database query. Just unplug your database connection and re-run the test.
The reason you have trouble testing is that you are using a global resource: your database connection. You would normally avoid this problem by providing your connection object to the test method (or class).

Categories