Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Statement being prepared, but not executed

I'm using the FOSFacebookBundle and the FOSUserBundle with Symfony2 to manage my users. I got everything working fine locally. However when I pushed everything to my staging environment, I noticed that the user's weren't persisted (using the doctrine entity manager) upon registration.

First thing I checked was if I could persist other stuff using the entity manager, which went fine. Next I went on and checked the logs and saw that the insert statement is there:

INSERT INTO user (username, username_canonical, email, email_canonical, enabled, salt, password, last_login, locked, expired, expires_at, confirmation_token, password_requested_at, roles, credentials_expired, credentials_expire_at, firstname, lastname, facebookID, date_of_birth, locale, gender, has_profile_pic, created_at, updated_at) 
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) 
({"1":"1234","2":"1234","3":"[email protected]","4":"[email protected]","5":true,"6":"","7":"","8":null,"9":0,"10":false,"11":null,"12":null,"13":null,"14":["ROLE_FACEBOOK"],"15":0,"16":null,"17":"Mr","18":"Foo","19":"1234","20":{"date":"1986-12-09 00:00:00","timezone_type":3,"timezone":"PRC"},"21":"nl_NL","22":"male","23":1,"24":{"date":"2012-07-06 01:34:47","timezone_type":3,"timezone":"PRC"},"25":{"date":"2012-07-06 01:34:47","timezone_type":3,"timezone":"PRC"}})

When I replace the question marks, with the values of the prepared statement and issue the query manually, everything works fine.

Has anyone got any clue as to what this could be? I would also be very happy with hints on how to further debug this, because I don't know where to look next..

Thanks in advance!

UPDATE:

I had another glance at the mysql log and I noticed that the INSERT statement is being prepared, but never executed (unlike the select statement). I can't find any errors in the error log. Here's the mysql log:

34 Prepare SELECT t0.username AS username1, t0.username_canonical AS username_canonical2, t0.email AS email3, t0.email_canonical AS email_canonical4, t0.enabled AS enabled5, t0.salt AS salt6, t0.password AS password7, t0.last_login AS last_login8, t0.locked AS locked9, t0.expired AS expired10, t0.expires_at AS expires_at11, t0.confirmation_token AS confirmation_token12, t0.password_requested_at AS password_requested_at13, t0.roles AS roles14, t0.credentials_expired AS credentials_expired15, t0.credentials_expire_at AS credentials_expire_at16, t0.id AS id17, t0.firstname AS firstname18, t0.lastname AS lastname19, t0.facebookID AS facebookID20, t0.date_of_birth AS date_of_birth21, t0.locale AS locale22, t0.gender AS gender23, t0.has_profile_pic AS has_profile_pic24, t0.created_at AS created_at25, t0.updated_at AS updated_at26 FROM user t0 WHERE t0.facebookID = ?

34 Execute SELECT t0.username AS username1, t0.username_canonical AS username_canonical2, t0.email AS email3, t0.email_canonical AS email_canonical4, t0.enabled AS enabled5, t0.salt AS salt6, t0.password AS password7, t0.last_login AS last_login8, t0.locked AS locked9, t0.expired AS expired10, t0.expires_at AS expires_at11, t0.confirmation_token AS confirmation_token12, t0.password_requested_at AS password_requested_at13, t0.roles AS roles14, t0.credentials_expired AS credentials_expired15, t0.credentials_expire_at AS credentials_expire_at16, t0.id AS id17, t0.firstname AS firstname18, t0.lastname AS lastname19, t0.facebookID AS facebookID20, t0.date_of_birth AS date_of_birth21, t0.locale AS locale22, t0.gender AS gender23, t0.has_profile_pic AS has_profile_pic24, t0.created_at AS created_at25, t0.updated_at AS updated_at26 FROM user t0 WHERE t0.facebookID = '1234'
34 Close stmt  

34 Query START TRANSACTION
34 Prepare INSERT INTO user (username, username_canonical, email, email_canonical, enabled, salt, password, last_login, locked, expired, expires_at, confirmation_token, password_requested_at, roles, credentials_expired, credentials_expire_at, firstname, lastname, facebookID, date_of_birth, locale, gender, has_profile_pic, created_at, updated_at) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
34 Close stmt  
34 Query COMMIT
34 Quit  

Any clues?

UPDATE 2:

I've been logging some return values of the execution of the PDO Statements down in the doctrine lib and it turns out that I get a normal return value (1) in my dev environment. However, I get no return value in my production environment. Seems like another hint, but I don't know what to make of it.

By the way PDOStatement::errorCodereturns 00000 (indicating everything went fine)

like image 608
Thomas K Avatar asked Jul 05 '12 17:07

Thomas K


People also ask

What happens if prepared statement is not closed?

Yes, you have to close the prepared statements ( PreparedStatement Object) and result sets as they may cause memory leakage.

When should prepared statements not be used?

It is easy: If you know the string comes from your application and cannot be manipulated by a user, then there is no need for prepared statements, because there is nothing to inject. If you are not sure (bad, but in greater projects not avoidable) use prepared statement.

What is the difference between a prepared statement and a statement?

Statement – Used to execute string-based SQL queries. PreparedStatement – Used to execute parameterized SQL queries.


Video Answer


1 Answers

There might be problem with connections on pdo_mysql on production settings. Check it once. Giving answer according to comment.

like image 176
Somnath Muluk Avatar answered Oct 06 '22 00:10

Somnath Muluk