You have probably come across this already but I have tripped up over this problem a few times.
If you have fields in the db like address_1, address_2, address_3 then the _ is not removed when using getter/setter methods
You have probably come across this already but I have tripped up over this problem a few times.
If you have fields in the db like address_1, address_2, address_3 then the _ is not removed when using getter/setter methods
A week or so I got an unexpected email from Ludek Vodicka asking me to have a look at ORM Designer for creating and maintaining my database schemas for the Symfony projects I have been working on. Up until now I have been using MySQL Workbench to create my ER-diagrams and maintain my database structure but I’ve come up against a few obstacles when trying to use it with projects using doctrine so I thought why now.
I fully expected ORM Designer to be a MySQL Workbench clone (and it’s obviously been a question that has been raised before – ORM Designer and MySQL Workbench comparison) but I must admit I was pleasantly surprised to find out is was not. To try and break myself into it easily I opted to start working on the database schema for the re-build of Manage My Alerts which I have intended to re-build using Symfony for quite a while.
continue reading…
The more traditional technique is to pass values to methods using individual parameters as in the example below:-
public function someMethod($name, $age = null) { // do something }
The benefit I have found with this method is that you can clearly identify what needs to be passed to the method, however, if you need to change the method to include an additional parameter it means that you have to update every call to this method so that every parameter is specified.
continue reading…
A few months ago I posted an article taking about how to get the raw SQL from a Doctrine Query Object but with the release of Symfony 1.3 and Symfony 1.4 it would appear that the code no longer works. As a result I’ve updated the code to work with Symfony 1.2 – 1.4 and you can find the updated source below:-
continue reading…
I am often importing data into a symfony project from an existing site or a CSV file and re-writing this data into the fixtures.yml is usually too complicated or time consuming so I end up writing bespoke import actions.
While I am writing these actions I often find that I have to delete the contents of the MySQL tables as you can never write the routine complete and accurate in one go so as you build it up in smaller steps you find that you have to get rid of the previously old data.
This presented me with 2 problems:-
This has been updated to work with Symfony 1.3/1.4 – Please go to the updated article: Raw SQL from Doctrine Query Object – Revised
As my use of Symfony is increasing I find myself frustrated that there doesn’t appear to be an easy way to get the raw SQL from a doctrine query object so I can simply output it and paste it into phpMyAdmin to debug problems with the SQL. I may be wrong about this but as yet I have not found a built in function to perform this operation.
Sure I am able to output the query with the “?” indicating where the necessary values are to go and I can also easily output the array of query parameters so I can substitute these manually but this takes time and it would be much much simpler and quicker to just output the whole query with the substitution already done so it’s a simply copy and paste of the raw SQL from the doctrine query object straight into phpMyAdmin.
I have wrote a quick function to do this and I had meant to post this for a while but I just have not had the chance to get round to it until now.
continue reading…
How many times have you searched for the answer to a problem in Google to find nothing but forums with people who have the same questions but no solutions posted even though the question was raised months, even years earlier?
If you post a question and no-one managed to provide you with an answer do you:-
Unfortunately there are a number of people in the latter category (myself included from time to time) and being a web developer means I run into this type of issue more than I would like but, I’ve recently come across yet another great reason why you should go back and answer your own question when you have managed to work out the answer.
continue reading…
Last week I was working away in the office at Line Digital on our latest Symfony based project when our project started giving us a strange error similar to:-
Fatal error: Uncaught exception ‘sfConfigurationException’ with message ‘Configuration file "/usr/lib/php/symfony/config/config/core_compile.yml" does not have a registered handler.’ in /usr/lib/php/symfony/config/sfConfigCache.class.php:101
Looking into this a little closer we found that the server had ran out of disk space so after making some space and using “symfony cc” to clear the cache we thought that this would have resolved the problem, however we continued to get the “does not have a registered handler” message being presented.