When using PHP PDO with SQLite, the error messages sometimes are not really self-explaining. Today I had an error stating "bind or column index out of range". The "column index" part made me check the tables index and data type.
When developing apps by using SQLite as a storage backend, you most likely will sometime get the error message:
The message very clearly describes what happened: you have prepared an SQL statement like "SELECT ... WHERE id=? OR id=? OR id=?" or at least something like that, and the placeholders (in this case the question marks) are too many.
Today I decided to provide a brief introduction into using SQLite compared to mySQL for PHP and webserver environments.
Traditionally mySQL is first choice when developing a dynamic website with PHP. Recently SQLite is another database system (I intentionally don't call it a database server, see below for reasons why) getting very popular. SQLite has two main usage areas: Webservers (mainly with little performance requirements) and applications.
In this quick article I'd like to comment a special case which is very much undocumented yet.
Zend_Date is a mighty class for handling date and time. As for all of such mighty tools, there is a heavy downside: it's really expensive at runtime. Using a Zend_Date instance a few times is no big deal, but using a hundred instances and generating thousands of ISO-style dates and times may take several seconds.
Today I eventually started optimizing the performance (thereby reducing server load a bit). It appeared some pages of my larger websites have grown to round about 300 kb causing some latency for lower bandwidth visitor. Having a quite good connection myself, I didn't care about that much in the past. But that's ab pity, because it is very simple to add compression to pure PHP-generated content.
Handling date and time in PHP makes most coders nervous. There are a bunch of functions playing arround with system time and timezone features, using UNIX timestamps and therefore are very limitted in application. At least I know a lot of guys born before 1970. Native Unix timestamps may be of great use for system level stuff like logging information or handling object lifetime, but not for real world scenarios: handling user age or historical events is impossible with 32 bit UNIX timestamps.
Goto is a very controversial programming statement. When discussing goto, some programmers talk about "spaghetti code" and think of BASIC, others answer with "performance" and think of C.
I'm one of the latter guys. My attitude to coding is, the coder should be able to decide what's the best way (in any means) to achieve the development goals.
Okay, there are only few good reasons to use the goto statement. Actually I can think of only one good reason: leaving a function at its end and place a generic cleanup there ("single point of exit").
Example:
PHP 5 introduces the E_STRICT error reporting constant. The PHP manual states "Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.". Thus it's recommendable to enable strict PHP errors.
Enabling the strict mode is done via the INI file (php.ini) or via code during runtime:
ini_set('error_reporting', E_ALL | E_STRICT);
The above code sets error_reporting to E_ALL and E_STRICT, because E_STRICT is not part of the E_ALL constant.
Smarty templates are a very useful tool and I'm addicted to Smarty for a couple of years now. All projects I did use Smarty templates. Now it's 2009 and PHP 5.2 is stable and has a good performance. Therefore I decided to use any of PHP 5's features when they come along my way.
Recently, Iterators came to close and I had to implement one. It's usefull for proxying and also for dynamically presenting views of lists. Therefore my implementation looks like:
class Foo { var $childs;